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I.  INTRODUCTION 


This  thesis  encompasses  a  complete  development  process. 
The  goal  of  this  process  is  to  produce  a  Finite  State  Ma¬ 
chine  (FSM)  controller  that  can  be  generated  by  a  silicon 
compiler.  This  development  supports  the  silicon  compiler 
project  at  the  Naval  Postgraduate  School. 

A.  SILICON  COMPILERS 

A  silicon  compiler1  is  a  collection  of  computer  programs 
that  translates  a  high-level  description  of  a  Very  Large 
Scale  Integrated  (VLSI)  circuit  into  a  complete  layout  that 
can  be  used  to  fabricate  the  circuit.  The  basic  function  of 
a  silicon  compiler  is  shown  in  Figure  1.1.  To  generate  a 
layout,  the  silicon  compiler  produces  instances  of  standard 
cells  and  interconnects  them  as  required  by  the  circuit  de¬ 
scription.  The  primary  advantages  of  a  silicon  compiler  are 
speed  and  reliability  of  design.  A  silicon  compiler  can 
produce  a  layout  in  minutes  that  would  take  months  for  a 
team  of  VLSI  designers.  A  good  silicon  compiler  will 
consistently  produce  correct  layouts.  A  layout  produced  by 
hand  may  include  errors.  The  disadvantage  of  using  a 


^-For  more  information  on  silicon  compilers,  see  Princi¬ 
ples  of  CMOS  VLSI  Design  (Weste  and  Eshraghian,  pp.  250-255, 
1985)  and  VLSI  Electronics:  Microstructure  Science 
(Einspruch,  Vol.  14,  pp.  115-138,  1986). 


Circuit  Description 


I 


Circuit  Layout 


Cell 

Library 


Figure  1.1  Silicon  Compiler 

silicon  compiler  is  efficiency.  A  layout  produced  by  a  sil¬ 
icon  compiler  may  be  larger  and  slower  than  a  layout  pro¬ 
duced  by  a  skilled  VLSI  designer.  Although  layouts  produced 
by  future  silicon  compilers  may  be  able  to  surpass  the  effi¬ 
ciency  of  layouts  produced  by  human  designers,  current  sili¬ 
con  compilers  are  most  effective  for  rapid  development  of 
custom  VLSI  circuits  that  will  not  have  large  production 
runs.  For  a  circuit  that  will  have  a  large  production  run, 
the  higher  efficiency  and  smaller  size  of  a  human  layout 
will  offset  the  increased  design  cost  that  can  be  amortized 
over  a  large  number  of  units.  Many  military  circuits  which 
have  small  production  runs  and  require  high  reliability  and 


short  development  time  are  ideal  for  current  silicon 
compilers,  provided  that  performance  requirements  can  be 
satisfied. 


B.  MONTEREY  SILICON  COMPILER  (MSC)  PROJECT 

The  Monterey  Silicon  Compiler  (MSC)  project  at  the  Naval 
Postgraduate  School  is  producing  a  technology  independent 
silicon  compiler.  Based  on  the  MacPitts2  silicon  compiler 
produced  by  MIT  Lincoln  Laboratory,  MSC  is  written  in  the 
LISP3  programming  language.  At  present,  MSC  is  essentially 
a  modified  version  of  MacPitts.  Thus,  the  nMOS  capabilities 
and  architecture  of  MSC  are  those  of  MacPitts.  Circuit 
design  specifications  processed  by  MSC  are  in  LISP  format. 
The  layout  produced  by  MSC  is  a  Caltech  Intermediate  Form 
(CIF)4  file  that  can  be  used  to  fabricate  a  circuit  at  many 
VLSI  foundries.  MSC  currently  supports  n-channel  Metal  Ox¬ 
ide  Semiconductor  (nMOS)  technology.  Present  development 
work  on  MSC  involves  the  addition  of  Scalable  Complementary 
Metal  Oxide  Semiconductor  (SCMOS)  technology.  The  micropro¬ 
grammed  controller  in  this  thesis  supports  the  SCMOS  tech¬ 
nology  addition  to  MSC. 

5  • 

Use  of  the  MacPitts  silicon  compiler  is  described  in 
Introduction  to  MacPitts  (MIT  RVLSI-3,  10  February  1983). 

3 MSC  is  written  in  Franz  Lisp.  For  more  information  on 
Franz  Lisp,  see  LISPcraft  (Wilensky,  1984) . 

4CIF  is  explained  in  A  Guide  to  LSI  Implementation  (Hon 
and  Sequin,  pp.  79-123,  January  1980). 


C.  MICROPROGRAMMED  CONTROLLER 

A  microprogrammed  controller  is  an  electronic  circuit 
that  generates  time  based  control  signals  for  other  cir¬ 
cuits.  The  general  configuration  of  a  microprogrammed  con¬ 
troller  is  shown  in  Figure  1.2.  It  contains  a  Read  Only 
Memory  (ROM)  and  next  address  logic.  The  ROM  words  contain 
information  for  controller  output  and  for  next  address  de¬ 
termination.  The  status  inputs  and  next  address  information 
are  used  by  the  next  address  logic  to  determine  the  next  ROM 
address.  If  each  output  signal  corresponds  to  one  bit  of 
the  words  in  the  ROM,  the  microprogram  format  is  horizontal. 
If  the  outputs  are  produced  by  decoding  a  smaller  number  of 


Figure  1.2  Microprogrammed  Controller 


4 


bits  in  the  ROM  words,  the  microprogram  format  is  vertical. 
Microprogrammed  controllers  are  used  in  many  applications 
from  traffic  lights  and  microwave  ovens  to  computers.  The 
MSC  application  of  a  microprogrammed  controller  contained  in 
this  thesis  is  similar  to  the  controller  in  a 
microprocessor . 

D.  NAME  CONVENTIONS 

Pile  name  extensions  and  the  file  type  associated  with 
them  are  listed  in  Table  1.1.  The  extension  is  the  last 
part  of  a  file  name.  The  library  file  is  an  exception  to 
the  file  name  extension  convention.  This  file  contains  LISP 


TABLE  1.1  FILE  NAME  EXTENSIONS  AND  FILE  TYPES 


File  Name  Extension 

File  Type 

No  Extension 

Executable  File 

.c 

C  Language  Source  File 

.cif 

CIF  File 

•  ext 

Circuit  Extraction  File 

.1 

LISP  Language  Source  File 

.mac 

MSC  Source  File 

.mag 

Magic  Layout  File 

.o 

Compiled  Object  File 

.obj 

MSC  Object  File 

.  sim 

Simulation  File 
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formatted  statements  that  are  interpreted  while  MSC  is 
running. 

E.  CONTENT  DESCRIPTION 

The  organization  of  this  thesis  matches  a  phased 
development  process.5 

1.  Analysis  Phase 

The  analysis  phase  includes  planning,  setting  goals, 
and  defining  requirements.  Chapter  II  starts  the  analysis 
phase  with  an  examination  of  the  nMOS  layout  produced  by  MSC 
and  development  of  architectural  requirements  for  the 
controller.  Chapter  III  includes  a  description  of  the  pro¬ 
grams  and  functions  in  the  nMOS  MSC  and  software  require¬ 
ments  for  the  controller.  Chapter  IV  completes  the  analysis 
phase  with  a  definition  of  MSC  controller  goals  and  a  fusion 
of  the  requirements  developed  in  Chapters  II  and  III. 

2 •  Design  Phase 

The  design  phase  starts  with  trade-off  studies  in 
Chapter  V.  In  this  chapter,  different  SCMOS  logic  struc¬ 
tures  and  controller  organizations  are  evaluated  using  the 
goals  and  requirements  of  Chapter  IV.  The  logic  structure 
and  controller  organization  selected  in  Chapter  V  are  used 
to  create  the  design  presented  in  Chapter  VI.  The  design  in 


5Based  on  the  phased  life-cycle  model  in  Software  Engi¬ 
neering  Concepts  (Fairley,  pp.  37-42,  1985). 
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Chapter  VI  is  in  two  sections.  One  section  is  technology 
independent  and  one  section  is  for  the  SCMOS  technology. 

3 .  Implementation  Phase 

The  implementation  phase  is  contained  in  Chapter 
VII.  The  first  part  of  implementation  involves  installation 
of  the  nMOS  MSC  and  modification  to  support  the  SCMOS  tech¬ 
nology.  The  second  part  of  implementation  involves  layout 
and  test  of  each  cell  in  the  SCMOS  section  of  Chapter  VI. 

4 .  Test  Phase 

The  test  phase  is  documented  in  Chapter  VIII.  This 
phase  involves  integration  and  test  of  controllers  con¬ 
structed  from  the  cells  generated  in  Chapter  VII.  The  sys¬ 
tems  produced  are  verified  against  the  design  in  Chapter  VII 
and  validated  against  the  requirements  in  Chapter  IV. 

5.  Maintenance  Phase 

The  maintenance  phase  of  the  controller  starts  with 
the  conclusions  presented  in  Chapter  IX.  These  conclusions 
involve  refinements  to  the  design,  methods  of  installing  the 
controller  in  MSC,  and  suggested  improvements  to  the  organi- 

I  zation  of  MSC.  Additional  research  in  support  of  MSC  is  in- 

I 

!  eluded  in  these  conclusions. 
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II.  MSC  TARGET  ARCHITECTURE 


Understanding  the  physical  and  functional  properties  of 
the  MSC  target  architecture  is  crucial  to  the  formulation  of 
requirements  for  the  microprogrammed  controller  that  is  the 
subject  of  this  thesis.  MSC  produces  layouts  for  complete 
nMOS  VLSI  circuits  that  may  include  one  or  more  finite  state 
machine  controllers. 

A.  PHYSICAL  LAYOUT 

An  MSC  layout  includes  pads,  a  control  logic  array,  a 
data  path,  a  flags  area,  and  distribution  structures  for 
signals  and  power.  Figure  2.1  shows  the  floor  plan  of  an 
MSC  nMOS  VLSI  layout.  The  perimeter  of  the  layout  is  a  pad 
frame  with  pads  on  three  sides.  The  pads  are  numbered  se¬ 
quentially  in  a  clockwise  direction  starting  at  the  left  pad 
on  the  top  edge.  Inside  the  pad  frame  is  a  frame  for  drain 
power  (Vdd)  and  ground  (GND)  distribution.  In  between  the 
pad  frame  and  the  Vdd  and  GND  frame  is  a  routing  channel  for 
signals  to  and  from  the  pads.  Inside  the  Vdd  and  GND  frame 
are  the  data  path,  flags  area,  and  control  logic  array.  The 
data  path  and  control  logic  array  are  separated  by  horizon¬ 
tal  clock  and  power  buses.  The  flags  area  is  to  the  right 
of  the  data  path.  The  pads  are  used  for  connections  between 
the  VLSI  circuit  and  the  package  that  encloses  it.  Word 
size  data  processing  is  accomplished  in  the  data  path  and 
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single  bit  processing  is  accomplished  in  the  control  logic 
array.  Word  size  data  storage  is  performed  in  the  data  path 
and  single  bit  storage  is  performed  in  the  flags  area. 

1.  Data  Path 

The  data  path  in  an  MSC  layout  is  the  area  that  con¬ 
tains  most  of  the  structures  used  for  data  processing  and 
data  storage.  It  is  organized  horizontally  in  bit  slices 
and  vertically  in  units.  This  organization  is  shown  in 
Figure  2.2.  Each  horizontal  bit  slice  contains  all  of  the 
processing  elements  for  one  bit  of  word  size  data.  Each 
vertical  unit  contains  similar  elements  that  perform  one 
function  on  all  bits  in  word  size  data  structures.  There 
are  five  types  of  units:  register,  output  port,  internal 
port,  bit,  and  organelle.  Register  units,  shown  in  Figure 
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Figure  2.2  Data  Path  Organization 
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2.31,  are  used  for  data  storage.  Output  port  units  are  used 
to  generate  multiple  bit  output  words  for  pads.  Internal 
port  units  are  used  to  generate  multiple  bit  words  for  use 
inside  the  data  path.  Output  port  units  and  internal  port 
units  have  the  same  internal  structure  as  shown  in  Figure 
2.4.  Bit  units,  shown  in  Figure  2.5,  are  used  to  extract 
groups  of  bits  for  the  control  logic  array  from  multiple  bit 
words  in  the  data  path.  Organelle  units,  shown  in  Figure 
2.6,  generate  single  bit  outputs  of  multiple  bit  logic  or 
arithmetic  functions.  Each  unit  may  include  one  or  two  mul¬ 
tiplexers  to  select  input  sources.  Each  unit  input  is 
called  an  argument.  Each  argument  source  is  called  an 
operand.  For  operands  that  are  constant,  the  operand  inputs 
are  hard  wired  to  ground  or  power  wo  force  constant  logical 
zero  or  one  inputs.  For  arguments  with  single  operands,  a 
degenerate  multiplexer  that  is  a  direct  connection  from  the 
operand  to  the  argument  is  used.  These  alternate 
multiplexer  configurations  are  shown  in  Figure  2.7.  Operand 
selection  for  the  multiplexers  in  each  unit  is  controlled  by 
a  bus  of  multiplexer  control  lines  from  the  control  logic 
array.  Each  multiplexer  control  line  enables  one  operand 
for  each  argument  in  the  unit.  Data  path  internal  buses, 

^■The  units  in  Figures  2.3  -  2.6  are  all  shown  with  two 
input  multiplexers  for  each  argument.  The  actual  number  of 
inputs  to  each  multiplexer  in  a  unit  is  determined  by  the 
number  of  unique  sources  and  constant  values  associated  with 
each  argument. 
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Figure  2.3  Register  Unit 
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Figure  2 . 4  Output  Port  and  Internal  Port  Units 
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Figure  2.7  Unit  Multiplexer  Options 


located  at  the  top  of  each  bit  slice,  connect  register. 


output  port,  internal  port,  bit,  and  organelle  units.  The 


bit  slices  are  stacked  to  form  the  data  path. 


2  .  Control  Logic  Arra^i 


The  control  logic  array  generates  control  and  data 


signals  that  are  sent  to  the  data  path  and  pads.  All  single 


bit  processing  is  performed  in  the  control  logic  array.  The 


inputs  to  the  array  are  signals  from  organelles,  registers. 


flags,  and  input  pads.  The  outputs  are  control  signals  for 


the  registers  and  multiplexers  or  data  signals  that  are  used 


for  setting  flags,  internal  signals,  or  output  pads.  The 
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current  nMOS  version  of  MSC  uses  a  Weinberger2  logic  array. 
Unlike  the  Programmable  Logic  Array  (PLA) ,  the  Weinberger 
array  is  composed  exclusively  of  NOR  gates.  For  example,  an 
exclusive  or  (XOR)  of  two  single  bit  signals  is  converted  to 
an  equivalent  combination  of  NOR  gates  in  the  control  logic 
array.  The  inputs  and  outputs  both  run  in  vertical  columns. 
Ground  distribution  is  also  done  in  vertical  columns.  The 
horizontal  tracks  are  used  to  determine  the  relationship  be¬ 
tween  the  inputs  and  outputs. 

B.  FINITE  STATE  MACHINE  (FSM)  ARCHITECTURE 

A  finite  state  machine  (FSM)  is  a  clocked  circuit  that 
"remembers  information  about  its  past  inputs" (Langdon,  1982, 
p  522) .  It  is  composed  of  combinational  logic  and  clocked 
memory  elements  that  store  state  variables.  "The  state  is 
the  totality  of  the  values  of  all  bits  ...  in  stor¬ 
age  ."(  Langdon  ,  1982,  p  522)  The  relationship  between  the 
inputs  and  outputs  is  determined  by  the  current  state  of  the 
machine.  During  each  clock  cycle,  new  values  of  the  state 
variables  are  loaded  into  the  memory  elements  and  the  ma¬ 
chine  transitions  to  a  new  state.  The  new  state  variable 
values  are  the  next  state  outputs  from  the  combinational 
logic.  These  next  state  outputs  are  based  on  the  current 
inputs  and  the  old  state  values  stored  in  the  memory 

2For  a  description  of  a  Weinberger  array  see  "Large 
Scale  Integration  of  MOS  Complex  Logic:  A  Layout 
Method" (Weinberger,  1967). 


elements.  There  are  two  types  of  FSMs,  the  Moore  FSM  and 
the  Mealy  FSM. 

1.  Moore  FSM 

The  Moore  FSM  shown  in  Figure  2.8  is  the  simplest 
form  of  FSM.  It  consists  of  storage  elements  for  the  state 
variables  and  combinational  logic  used  to  determine  the  next 
values  of  the  state  variables  based  on  the  current  values  of 
the  state  variables  and  the  input  signals.  The  outputs  are 
functions  of  only  the  state  variables.  The  input  signals 
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Figure  2 . 8  Moore  Finite  State  Machine 


affect  the  next  state  but  not  the  current  outputs.  As  a 
result,  the  outputs  only  change  during  state  transition. 


2.  Mealv  FSM 

The  other  type  of  FSM,  the  Mealy  FSM,  is  shown  in 
Figure  2.9.  In  a  Mealy  FSM,  the  outputs  are  functions  of 
the  state  variables  and  the  input  signals.  The  output  sig¬ 
nals  may  change  in  response  to  changes  in  the  input  signals. 
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Figure  2.9  Mealy  Finite  State  Machine 
3.  Moore  FSM  Timing 

The  timing  relationships  between  the  input  and  out¬ 
put  signals  of  a  Moore  FSM  are  shown  in  Figure  2.10.  The 
inputs  must  be  stable  prior  to  state  transition  for  a  length 
of  time  equal  to  the  sum  of  the  setup  time  for  the  registers 
and  the  maximum  delay  time  for  the  combinational  logic.  The 
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Figure  2.10  Moore  FSM  Timing 

inputs  must  remain  stable  after  state  transition  (clock 
edge)  long  enough  to  satisfy  register  hold  time 
requirements.  The  outputs  of  a  Moore  FSM  become 
undetermined  at  state  transition  and  remain  undetermined  for 
the  duration  of  the  register  and  combinational  logic  delays. 
After  the  outputs  have  stabilized,  they  remain  stable  until 
the  next  state  transition. 


4. 


The  timing  relationships  between  the  input  signals 
and  output  signals  that  depend  only  on  state  variables  of 
the  Mealy  FSM  are  the  same  as  the  relationships  between  the 
input  and  output  signals  of  the  Moore  FSM  shown  in  Figure 
2.10.  The  timing  relationships  between  the  input  signals 
and  output  signals  that  are  dependent  on  state  variables  and 
input  signals  of  a  Mealy  FSM  are  shown  in  Figure  2.11.  Like 
the  Moore  FSM,  the  inputs  to  the  Mealy  FSM  must  be  stable 
prior  to  state  transition  for  a  length  of  time  equal  to  the 
sum  of  the  setup  time  for  the  registers  and  the  maximum 
delay  time  for  the  combinational  logic.  The  inputs  must 
remain  stable  after  state  transition  (clock  edge)  long 
enough  to  satisfy  register  hold  time  requirements.  The 
outputs  of  a  Mealy  FSM  become  undetermined  at  state 
transition  and  remain  undetermined  for  the  duration  of  the 
register  and  combinational  logic  delays.  After  the  outputs 
that  depend  only  on  state  variables  have  stabilized,  they 
remain  stable  until  the  next  state  transition.  The  outputs 
that  also  depend  on  current  inputs  are  stable  only  when  the 
inputs  they  depend  on  have  been  stable  long  enough  for  the 
outputs  of  the  combinational  logic  to  stabilize. 

5.  State  Transition  Diagram 

An  FSM  has  a  fixed  number  of  states.  It  can  transi¬ 
tion  to  a  subset  of  these  states  based  on  the  current  state. 
In  a  state  transition  diagram,  this  is  represented  as  a 
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Figure  2 . 11  Mealy  FSM  Timing 

graph  with  nodes  for  the  states  and  directed  branches  for 
available  state  transitions.  The  choice  of  which  branch  to 
take  from  a  node  is  based  on  inputs  to  the  FSM. 

6.  Moore  FSM  State  Transition  Diagram 

In  the  state  transition  diagram  for  a  Moore  FSM,  the 
outputs  are  associated  with  the  nodes.  An  example  of  a 
Moore  FSM  state  transition  diagram  for  a  J-K  flip-flop  is 


shown  in  Figure  2.12.  The  J-K  flip-flop  is  a  simple  FSM 
with  a  single  binary  state  variable.  This  single  state 
variable  is  also  the  output  of  the  J-K  flip-flop.  There  are 
two  states  A  and  B.  When  the  FSM  is  in  state  A,  the  output 
is  zero.  When  the  FSM  is  in  state  B,  the  output  is  one. 
These  states  are  drawn  as  circular  nodes.  Each  node  has 
branches  leaving  it  that  return  to  the  same  node  or  transi¬ 
tion  to  the  other  node.  The  branches  represent  the  values 
of  the  input  signals  during  the  next  state  transition.  If 
the  current  state  is  A  and  J  is  one,  the  next  state  will  be 
B.  This  is  the  lower  branch.  If  the  current  state  is  A  and 
J  is  zero,  the  next  state  will  be  A.  This  is  the  left 
branch  that  returns  to  the  same  state.  If  both  J  and  K  are 


Figure  2.12  Moore  FSM  State  Transition  Diagram 


zero,  the  state  does  not  change.  If  both  J  and  K  are  one, 
the  state  will  alternate  between  A  and  B  every  clock  cycle. 

7 .  Mealy  FSM  State  Transition  Diagram 

The  state  transition  diagram  for  a  Mealy  FSM  is  sim¬ 
ilar  to  the  state  transition  diagram  for  a  Moore  FSM.  The 
only  difference  is  that  in  the  Mealy  FSM  state  transition 
diagram,  the  outputs  are  associated  with  the  branches.  An 
example  of  a  Mealy  FSM  state  transition  diagram  for  a  tran¬ 
sition  detector  circuit  is  shown  in  Figure  2.13.  A  transi¬ 
tion  detector  compares  the  current  input  with  the  input  at 
the  last  state  transition.  If  they  are  the  same,  no  transi¬ 
tion  has  occurred  and  a  zero  is  output.  If  the  current  and 
previous  inputs  are  different,  a  transition  has  occurred  and 
a  one  is  output.  The  state  transition  diagram  also  has  two 
states  A  and  B.  State  A  corresponds  to  a  zero  input  at  the 
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Figure  2.13  Mealy  FSM  State  Transition  Diagram 


last  state  transition  and  state  B  corresponds  to  a  one  input 
at  the  last  state  transition.  The  left  label  on  each  branch 
is  the  current  input  and  the  right  label  on  each  branch  is 
the  current  output. 

C.  MSC  FSM  STRUCTURE 

The  layout  produced  by  MSC  may  contain  one  or  more  modi¬ 
fied  Mealy  FSMs.  The  structure  of  these  FSMs  is  shown  in 
Figure  2.14.  The  only  state  variable  used  by  each  of  these 
FSMs  is  a  state  number.  The  state  number  is  an  unsigned 
integer  in  the  range  of  0  to  2W  -  1,  where  W  is  the  data 
path  word  size.  The  maximum  number  of  states  for  each  FSM 
is  2W.  Each  FSM  may  include  a  fixed  depth  stack  and  an 
incrementer  for  state  numbers.  The  selection  control  of  the 
multiplexer  and  the  push/pop  controls  of  the  optional  state 
number  stack  are  determined  by  the  MSC  design  specification 
of  the  current  state.  If  the  current  state  description  con¬ 
tains  a  call  statement,  the  multiplexer  selects  a  call  state 
number  from  the  combinational  logic  and  a  return  state  from 
the  incrementer  is  pushed  onto  the  stack.  In  this  way,  the 
FSM  transitions  to  the  state  specified  in  the  call  statement 
and  the  number  of  the  state  following  the  call  statement  is 
pushed  onto  the  stack  for  use  by  a  return  statement.  If  the 
current  state  description  contains  a  return  statement,  the 
multiplexer  selects  the  return  state  number  on  the  top  of 
the  stack  and  the  stack  is  popped.  This  causes  the  FSM  to 
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Figure  2.14  MSC  Finite  State  Machine 

transition  to  the  state  following  the  state  with  the  most 
recently  executed  call  statement.  The  calls  and  returns  may 
be  nested  so  that  a  subroutine  may  call  another  subroutine, 
or  a  subroutine  may  call  itself  recursively.  There  is  no 

I 
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checking  for  stack  overflow  or  underflow  on  subroutine  calls 
and  returns.  The  stack  depth  specified  in  the  MSC  design 


specification  for  a  process  must  be  large  enough  to  accommo¬ 
date  the  deepest  nesting  of  subroutines  expected  in  the 
process.  This  depth  may  be  difficult  to  estimate  for 
recursive  subroutines.  If  the  current  state  description 
contains  a  go  statement,  the  multiplexer  selects  the  go 
state  number  from  the  combinational  logic.  If  the  current 
state  (other  than  the  last  state  in  a  process)  does  not  in¬ 
clude  a  call,  return,  or  go  statement,  the  multiplexer  se¬ 
lects  the  next  state  number  from  the  incrementer.  The  last 
state  in  a  process  contains  an  implicit  go  statement  to  the 
first  state  in  the  process.  This  implicit  go  statement  is 
overridden  by  any  go,  call,  or  return  statements  in  the  last 
state  of  a  process.  The  incrementer  is  used  to  determine 
the  next  sequential  state.  If  a  design  has  more  than  one 
process,  each  of  the  processes  is  controlled  by  a  separate 
FSM. 

D.  MULTIPLE  FSM  INTERACTION 

There  is  a  separate  FSM  for  each  process.  The  separate 
FSMs  simultaneously  control  the  common  data  processing  and 
storage  elements  as  shown  in  Figure  2.15.  These  processes 
communicate  with  each  other  by  registers,  flags,  signals, 
and  internal  ports.  An  MSC  register  is  a  multiple  bit  data 
structure  that  continuously  stores  a  value  and  has  the  same 
number  of  bits  as  the  data  path  word  size.  A  flag  is  a  one 
bit  data  structure  that  continuously  stores  a  value.  A 
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Figure  2 . 15  Multiple  FSM  Interaction 


signal  is  a  one  bit  data  structure  that  only  has  a  value 


during  the  state  in  which  its  value  is  set.  An  internal 


port  is  a  multiple  bit  data  structure  that  has  the  same 


number  of  bits  as  the  data  path  word  size  and  only  has  a 


value  during  the  state  in  which  its  value  is  set.  Each 


register,  flag,  signal,  or  internal  port  is  controlled  by  a 


single  FSM  controller. 


1.  nMOS  Multiplexer  Wired  AND  Logic 


The  multiplexers  used  in  the  nMOS  version  of  MSC  produce  a 


logical  AND  of  their  input  values  when  more  than  one  input 


is  selected  simultaneously.  This  would  happen  when  a  par 


statement  or  a  single  alternative  of  a  cond  statement  for  a 
state  in  a  process  or  an  always  statement  in  the  design 
specification  assigns  multiple  values  to  a  register  or  port. 
The  following  three  segments  of  a  design  specification 
attempt  to  assign  the  value  of  b  to  a  and  the  value  of  c  to 
a  simultaneously: 

(always  (setq  a  b)  (setq  a  c) ) 

(par  (setq  a  b)  (setq  a  c) ) 

(cond  (t  (setq  a  b)  (setq  a  c) ) ) 

The  action  of  the  wired  AND  produced  by  the  nMOS 
transmission  gate  multiplexers  used  in  MSC  is  shown  in  Fig¬ 
ure  2.163.  This  shows  the  outputs  of  two  inverters  con¬ 
nected  to  the  transmission  gate  multiplexer  in  the  center  of 
the  figure.  The  output  of  the  multiplexer  is  labeled  Out. 
The  selection  controls  of  the  multiplexer  are  labeled  Sel  1 
and  Sel  2.  The  inputs  to  the  inverters  are  labeled  In  1  and 
In  2.  The  inputs  to  the  multiplexer  are  the  complements  of 
the  inputs  to  the  inverters  or  (NOT  In  1)  and  (NOT  In  2) . 
These  input  signals  to  the  multiplexer  are  low  when  the  in¬ 
puts  to  the  corresponding  inverters  are  high  causing  the 
enhancement  mode  pull  down  transistors  to  conduct  and  pull 
the  outputs  down  to  GND.  The  input  signals  to  the 
multiplexer  are  high  when  the  inputs  to  the  corresponding 


3For  a  description  of  the  symbols  used  in  this  schematic 
and  all  subsequent  schematics,  see  Figure  1.11(b)  on  page  12 
of  The  Design  and  Analysis  of  VLSI  Circuits  (Glasser  and 
Dobberpuhl,  p.  12,  1985). 
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Figure  2 . 16  Multiplexer  Wired  AND  Logic 

inverters  are  low  causing  the  enhancement  mode  pull  down 
transistors  to  be  cut  off  which  allows  the  depletion  mode 
pull  up  transistors  to  pull  the  outputs  up  to  Vdd.  If  only 
one  of  the  Sel  signals  is  high,  the  signal  at  Out  is  the 
normal  output  of  the  corresponding  inverter.  If  both  of  the 
Sel  signals  are  high,  the  outputs  of  both  inverters  are  con¬ 
nected  to  the  output  of  the  multiplexer.  This  also  connects 
the  outputs  of  the  inverters  to  each  other  allowing  either 
pull  down  transistor  to  pull  down  all  outputs.  This  turns 
the  entire  circuit  into  a  NOR  gate  where  the  output  is  (NOT 
(In  1  OR  In  2)).  This  can  be  converted  to  ((NOT  In  1)  AND 


(NOT  In  2))  by  DeMorgan's  Laws4.  This  is  the  logical  AND  of 
the  inputs  to  the  multiplexer.  This  nMOS  wired  AND  in  the 
multiplexer  includes  the  side  effect  that  the  outputs  of  the 
inverters  are  the  AND  of  the  normal  outputs  throughout  the 
circuit.  If  one  of  the  inputs  to  the  multiplexer  is  a 
register,  the  value  stored  in  the  register  is  forced  to  the 
logical  AND  of  the  inputs  to  the  multiplexer.  This  reverses 
the  normal  signal  flow  from  the  output  of  a  register  to  the 
input  of  a  multiplexer.  This  wired  AND  can  destroy  a  cir¬ 
cuit  if  one  of  the  inputs  is  a  constant  high  (Vdd)  and  the 
other  is  a  constant  low  (GND) .  If  the  multiplexer  selects 
both  these  inputs  simultaneously,  there  is  a  direct  path 
from  Vdd  to  GND  that  would  probably  burn  out  the 
multiplexer.  The  current  nMOS  MSC  cannot  generate  a 
multiplexer  that  is  controlled  toy  two  processes.  The  inter¬ 
nal  functional  simulation  of  MSC  generates  an  error  if  any 
of  the  multiplexers  in  a  design  specification  can  have  more 
than  one  input  selected  at  a  time.  The  ESIM  switch  level 
simulations  of  nMOS  MSC  designs  with  multiple  simultaneous 
inputs  to  multiplexers  verify  the  operation  of  the  wired  AND 
logic. 

2.  SCMOS  Multiplexer  Logic 

The  SCMOS  multiplexer  and  the  nMOS  multiplexer 
should  have  the  same  function.  SCMOS  circuits  use  low 

4For  a  statement  of  DeMorgan's  Laws  and  logical  tautolo¬ 
gies,  see  Introduction  to  LOGIC ( Suppes .  p.  34,  1957). 
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impedance  pull  up  and  pull  down  structures.  This  precludes 
the  use  of  wired  logic.  The  SCMOS  multiplexer  cannot  dupli¬ 
cate  the  operation  of  the  nMOS  multiplexer  for  multiple  si¬ 
multaneous  input  selections.  Since  multiple  simultaneous 
input  selections  to  multiplexers  generate  errors  for  the  in¬ 
ternal  functional  simulation  of  MSC  and  cause  differences 
between  SCMOS  and  nMOS  circuits,  multiple  simultaneous  input 
selections  to  multiplexers  should  not  be  supported  by  MSC. 
The  SCMOS  multiplexer  should  function  as  a  true  multiplexer 
with  no  side  effects. 

E .  ARCHITECTURAL  REQUIREMENTS 

The  MSC  target  architecture  implies  required  character¬ 
istics  of  a  controller.  The  controller  must  be  composed  of 
multiple  Mealy  FSMs.  Each  FSM  must  have  a  single  state 
variable  that  is  the  state  number.  Each  FSM  must  be  able  to 
include  an  incrementer  and  subroutine  stack.  Each  unit  in 
the  data  path  must  be  controlled  by  a  single  FSM  or  always 
using  true  multiplexers  that  produce  no  side  effects.  These 
requirements  will  be  used  to  evaluate  the  suitability  of 
controller  designs. 


The  internal  structure  of  MSC  is  based  on  the  MacPitts 
silicon  compiler.  Since  MSC  is  currently  a  modified  version 
of  MacPitts,  the  internal  structures  of  the  two  silicon  com¬ 
pilers  are  identical.  Analysis  of  the  MSC  structure  is  used 
to  generate  requirements  for  the  controller  and  to  eliminate 
design  alternatives  that  are  not  consistent  with  this  struc¬ 
ture.  MSC  is  a  collection  of  programs  that  extract  informa¬ 
tion  from  a  design  specification  to  produce  a  functional 
simulation  of  the  specification  or  a  Caltech  Intermediate 
Form  (CIF)1  file  describing  a  VLSI  circuit  that  implements 
the  specification. 

A.  DATA  PRIMITIVES 

There  are  four  data  primitives  defined  for  MSC:  signal, 
flag,  port,  and  register.  These  are  shown  in  Table  3.1. 
The  MSC  data  primitives  correspond  to  internal  nodes  in  a 
VLSI  circuit.  Signals  and  flags  represent  single  bit  nodes 
and  ports  and  registers  represent  multibit  nodes.  The  num¬ 
ber  of  bits  in  ports  and  registers  is  determined  by  the 
word-size  specified  in  a  design  specification.  All  ports 
and  registers  in  a  MSC  VLSI  circuit  have  the  same  number  of 

^■For  a  description  of  the  format  and  use  of  CIF  files, 
see  the  CIF  primer  in  A  Guide  to  LSI  Implementation  (Hon. 


1980,  pp.  79-123). 


bits.  Signal  and  port  nodes  do  not  have  memory  while  flag 
and  register  nodes  do  have  memory.  Nodes  that  do  not  have 
memory  have  valid  data  only  during  a  state  that  assigns  a 


value  to  them.  Nodes  with  memory  retain  the  values  that 
were  last  assigned  to  them  until  the  next  state  transition. 
If  no  new  value  is  assigned  to  a  node  with  memory  during  a 
state  transition,  the  node  retains  its  previous  value. 
Signals  and  ports  may  be  internal  or  external.  External 
nodes  are  associated  with  pads  in  a  MSC  VLSI  circuit  and 
internal  nodes  are  not  associated  with  pads. 


TABLE  3.1  DATA  PRIMITIVES 


Single 

Bit 

Multi- 

Bit 

No  Memory 

signal 

port 

Memory 

flag 

register 

B.  DATA  STRUCTURES 

Understanding  a  program's  data  structures  is  a  prerequi¬ 
site  to  understanding  its  operation.  The  data  structures  of 
a  computer  program  limit  the  information  that  it  can  input, 
manipulate,  and  output.  MSC  uses  a  combination  of  program 
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defined  and  defstruct2  data  structures.  Program  defined 
data  structures  are  those  that  are  not  explicitly  stated  in 
the  program  source  code.  The  program  defined  data  struc¬ 
tures  are  implied  by  the  functions  that  create  instances  of 
these  data  structures  or  access  information  in  them.  All  of 
these  functions  are  defined  in  the  MSC  source  code. 
Defstruct  data  structures  are  explicitly  stated  using  the 
defstruct  macro.  All  functions  to  create  instances  of 
defstruct  data  structures  or  access  information  in  them  are 
automatically  generated  by  the  defstruct  macro.  Both  of 
these  methods  use  Lisp  lists  to  store  data.  A  design  speci¬ 
fication3  is  a  text  file  that  contains  a  functional  descrip¬ 
tion  of  a  VLSI  circuit  to  be  compiled  by  MSC.  Both  the 
design  specification  and  the  library4  program  are  read  by 
MSC  at  run  time.  The  definition  and  eval  data  structures  in 
the  design  specification  are  written  by  the  user.  The 
definition  and  eval  data  structures  in  the  library  program 
are  part  of  the  MSC  program.  The  functions  that  extract 

2Defstruct  is  a  Lisp  define  structure  macro  in  the  lin- 
coln.l  program.  The  defstruct  macro  defines  a  Lisp  data 
structure  by  creating  all  of  the  functions  required  to  gen¬ 
erate  an  instance  of  the  structure  and  to  access  all  parts 
of  the  structure. (Malagon-Fajar,  1986,  pp.  87-95) 

3An  MSC  design  specification  is  a  text  file  whose  name 
ends  in  .mac.  The  data  structures  used  an  MSC  design  speci¬ 
fication  are  described  in  An  Introduction  to  MacPittsfMIT 
RVLSI-3 ,  1983). 

4The  organization  and  use  of  the  library  program  is  dis¬ 
cussed  in  Paragraph  III.D.7. 


information  from  these  structures  are  located  in  the 
prepass. 1  and  general. 1  programs.  All  other  data  structures 
are  created  and  accessed  by  functions  generated  by  the 
def struct  macro.  The  layout  structure  for  an  item  composed 
of  points,  rectangles,  symbol  names,  and  operators  and  the 
hierarchical  symbol  layout  data  structure  are  defined  in  the 
program  L5.1.  The  symbol  data  structure  is  created  and  ma¬ 
nipulated  by  functions  in  the  L5.1  program.  The  object 
structure  in  an  .obj  file,  the  extraction  structure  used  to 
produce  it,  and  other  internal  data  structures  are  defined 
in  the  program  defstructs.l. 

C.  CONTROL  AND  DATA  FLOW 

The  control  flow  of  MSC  is  shown  in  Figure  3.1.  The  MSC 
compiler  is  controlled  by  the  top  level  function  macpitts- 
compiler  in  prepass. 1.  At  the  start  of  a  compilation, 
command  line  options  are  processed  by  functions  in 
prepass. 1.  If  a  functional  simulation  is  requested,  the  de¬ 
sign  specification  is  interpreted  by  functions  in  the  pro¬ 
gram  interpret. 1.  The  design  specification  file  and  library 
file  are  read  by  functions  in  prepass. 1.  Definition  extrac¬ 
tion,  eval  evaluation,  macro  expansion,  and  constant  substi¬ 
tution  are  performed  by  functions  in  prepass. 1  and  general. 1 
on  the  information  in  the  design  specification  file  and 
library.  The  compiled  organelles. o  program  is  loaded  by  an 
eval  structure  in  library.  If  an  .obj  file  is  requested, 


the  data  path,  flags,  control,  and  pad  information  for  the 
object  structure  in  the  file  is  extracted  and  reduced  by 
functions  in  extract.  1.  If  an  .obj  file  is  not  requested 
and  an  .obj  file  exists,  the  .obj  file  is  read  into  an 
object  structure  by  the  get-object  function  in  prepass. 1. 
If  CIF  output  is  requested,  the  object  structure  is  con¬ 
verted  into  an  item  by  the  layout-object  function  in  the 
frame.  1  program.  The  item  is  output  in  CIF  format  by  the 
cifout  function  in  L5.1. 


D.  PROGRAM  COMPONENTS 

MSC  is  generated  under  the  control  of  a  Makefile5  by 
loading  compiled  programs  into  Franz  Lisp  and  using  the 
dumplisp  function  to  save  the  resulting  Lisp  environment  in 
an  executable  file.  One  program  source,  c-routines.c,  is 
written  in  the  C  programming  language.  All  other  program 
sources  are  written  in  Lisp. 


Program  lincoln.l 


Program  lincoln.l  contains  MIT  Lincoln  Laboratory 


general  purpose  extensions  to  the  Franz  Lisp  environment. 


Functions  to  add  use  of  the  vi  editor  from  inside  the  Franz 
Lisp  environment,  access  to  the  UNIX6  curses7  terminal 


5For  a  description  of  the  make  utility,  see  "Made  to  Or¬ 
der"  (Shelly  ,  1986,  pp.  128-131)  or  Make  -  A  Program  for 
Maintaining  Computer  Programs (Feldman.  1978) . 

6UNIX  is  a  Trademark  of  Bell  Laboratories. 


screen  updating  and  cursor  movement  optimization  package, 
APL8  like  operators  for  lists,  set  functions,  list  selection 
functions,  numeric  functions,  and  program  beautification 
macros  to  Franz  Lisp  and  the  Liszt  compiler.  The  most  im¬ 
portant  component  of  lincoln.l  is  the  defstruct  (define 
structure)  macro.  The  defstruct  macro  is  used  to  define  the 
majority  of  the  data  structures  used  in  MSC. (Crouch,  1984) 

2 .  Program  c-routines.c 

The  program  c-routines.c  is  the  only  component  of 
MSC  that  is  written  in  the  C  programming  language.  The 
functions  in  this  program  provide  Franz  Lisp  bindings  for 
the  routines  in  the  UNIX  curses  library.  The  compiled  ver¬ 
sion  of  this  program,  c-routines. o,  is  loaded  by  lincoln.l. 
The  only  component  of  MSC  that  uses  these  routines  is 
interpret. 1.  Interpret. 1  uses  the  routines  in  c-routines.c 
to  update  the  terminal  display  during  functional  simulation 
of  a  design  specification. 


7Curses  is  a  library  of  terminal  independent  screen  up¬ 
dating  functions. (UNIX  Programmer's  Manual.  1983,  Section 
3X)  and  (Arnold,  not  dated) . 

O 

"APL  n.  [...A  Programming  Language.]  A  language,  de¬ 
vised  by  K.  Iverson  (1961),  so  compacted  that  the  source 
code  can  be  freely  disseminated  without  revealing  the  pro¬ 
grammer's  intentions  or  jeopardizing  proprietary 
rights. " (Kelly-Bootle,  1981,  p.  13) 
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3. 


Program  L5.1  implements  the  L5y  language  for  mask 


level  integrated  circuit  layout.  It  contains  the  def struct 


definitions  for  the  item  and  symbol  data  structures.  CIF 


file  output  of  these  structures  is  performed  by  the  function 


cifout.  The  functions  in  L5.1  are  used  by  all  layout  func¬ 


tions  in  MSC.  CIF  output  compatible  with  the  Magic  layout 


editor,  SCMOS  layout  primitives,  and  a  layout-label  option 


in  the  item  data  structure  are  additions  to  MSC  that  support 


development  of  the  microprogrammed  controller  described  in 


Chapter  VI. 


Program  def structs . 1 


The  def structs. 1  program  contains  definitions  of 


object,  extraction,  and  other  internal  data  structures. 


Functions  to  support  these  data  structures  are  all  generated 


by  the  def struct  macro  in  lincoln.l. 


5.  Program  front-page. 1 


The  front-page  program  is  loaded  by  the  include 


function  during  compilation  of  MSC  Lisp  programs.  This  pro¬ 


gram  establishes  global  variables  required  by  MSC  and  uses 


the  fasl  function  to  load  the  lincoln.o,  L5.o,  and 


def structs. o  programs. 


yFor  a  description  of  the  L5  layout  language,  see  L5 
Jser 's  Guide (MIT  RVLSI-5,  7  March  1984). 


6. 


The  prepass. 1  program  includes  the  top  level  func¬ 
tions  of  MSC.  All  MSC  operations  are  controlled  by  the 
macpitts-compiler  function  in  this  program.  Included  in 
prepass. 1  are  functions  that  process  command  line  options. 
If  the  command  line  includes  the  "int"  option,  the  macpitts- 
compiler  function  calls  the  interpret  function  in 
interpret. 1  to  perform  a  functional  simulation.  If  the  com¬ 
mand  line  includes  the  "cif"  option,  the  macpitts-compiler 
uses  other  functions  in  prepass. 1  to  read  a  design  specifi¬ 
cation  and  library,  extract  definitions,  evaluate  evals,  ex¬ 
pand  macros,  and  perform  constant  substitutions.  The 
macpitts-compiler  function  uses  functions  in  extract. 1  to 
convert  the  definitions  into  an  extraction  data  structure. 
The  macpitts-compiler  function  converts  the  extraction  data 
structure  into  an  object  data  structure  to  pass  to  the 
layout-object  function  in  frame. 1. 

7 .  Program  library 

The  library  program  is  a  text  file  that  contains 
definition  and  eval  data  structures.  The  library  program 
starts  with  a  library  definition  followed  by  constant  defi¬ 
nitions,  macro  definitions,  function  definitions,  test 
definitions,  and  organelle10  definitions.  The  library  defi¬ 
nition  marks  the  beginning  of  the  library  definitions  in  an 


10"An  organelle  is  the  actual  layout  of  a  single  bit  of 
a  function. "(MIT  RVLSI-3,  10  February  1983,  p  25) 
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object.  This  mark  is  used  to  remove  the  library  definitions 
from  an  object  before  it  is  written  to  an  .obj  file.  The 
constant  definitions  and  macro  definitions  are  used  to  ex¬ 
pand  elements  of  the  design  specification  file  into  compo¬ 
nents.  Components  are  used  to  construct  extraction  data 
structures.  The  function  definitions  and  test  definitions 
are  used  by  the  interpret. 1  program  to  perform  a  functional 
simulation  of  the  design  specification  and  by  the  expand- 
form  function  in  the  prepass. 1  program  to  validate  functions 
and  tests  in  a  design  specification.  The  organelle  defini¬ 
tions  are  used  by  the  data-path.l  program  to  instantiate  an 
organelle  (layout  an  instance  of  an  organelle)  and  to  pro¬ 
vide  information  about  the  dimensions,  connections, 
electrical  characteristics,  and  logical  function  of  an 
organelle.  The  library  program  also  contains  an  eval  func¬ 
tion  that  loads  the  organelles. o  program.  The  library  pro¬ 
gram  is  interpreted  at  run  time.  Three  UNIX  directories  are 
searched  to  find  the  library  program.  First,  the  current 
directory  is  searched  for  the  library  program.  Next,  a  sub¬ 
directory  of  the  user's  home  directory  named  macpitts  is 
searched.  Finally,  the  directory  contained  in  the  macpitts- 
directory  Lisp  variable  is  searched.11  The  first  library 
program  found  by  this  search  is  read  by  the  get-library 
function  in  the  prepass. 1  program. 

11For  a  description  of  the  UNIX  directory  system,  see 
(McGilton  and  Morgan,  1983,  pp.  33-83). 
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The  organelles. 1  program  contains  all  of  the 
technology  dependent  functions  required  to  layout  organelles 
in  the  data  path.  The  nMOS  version  of  organelles. 1  contains 
building  blocks  to  construct  basic  inverter,  NAND,  and  NOR 
gates.  These  gates  are  combined  to  form  more  complex  func¬ 
tions.  Input  and  output  structures  are  added  to  the  func¬ 
tions  to  form  organelles.  The  SCMOS  version  of  organelles. 1 
does  not  use  a  hierarchical  method  to  construct  organelles. 
The  SCMOS  organelles  are  constructed  as  single  items  based 
on  Magic12  layouts.  The  functions  in  organelles. 1  are 
called  by  the  organelle  definitions  in  the  library  program. 
The  compiled  organelles. o  program  is  loaded  at  run  time  by 
an  eval  in  the  library  program. 

9.  Program  general. 1 

The  general. 1  program  contains  general  purpose 
layout  aids,  a  river  router,  controller  track  allocation 
functions,  look  up  and  query  functions  for  data  structures, 
and  display  functions.  The  layout  aids  are  functions  that 
produce  nMOS  superbuffers.  The  river  router  is  a  simple 
router  used  to  construct  the  connections  between  the  control 
logic  array  and  the  data  path.  The  river  router  is  also 
used  by  the  layout-organelle  function  in  the  data-path.l 
program  to  construct  the  data  path  internal  bus.  The  track 

12Magic  is  a  VLSI  layout  editor  program. 
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wtr, 


allocation  functions  are  used  to  determine  the  tracks 


(horizontal  signal  connections)  that  correspond  to  the  re¬ 
quired  signals  in  the  control  logic  array.  The  look  up  and 
query  functions  for  data  structures  are  used  to  access  the 
definitions  part  of  the  object  data  structure.  The  display 
functions  are  used  to  display  notes ,  warnings,  statistics, 
and  heralds.  Note  and  warning  functions  print  error  and 
warning  messages  on  the  console.  Statistic  and  herald  func¬ 
tions  print  general  information  messages  on  the  console. 
Printing  of  these  messages  is  controlled  by  the  stat, 
nostat,  herald,  and  noherald  command  line  options.  Herald 
messages  include  the  total  Central  Processor  Unit  (CPU)  time 
and  the  amount  of  CPU  time  used  for  garbage  collection. 
These  times  are  displayed  in  sixtieths  of  a  second. 

10.  Program  extract. 1 

Program  extract. 1  is  used  by  the  get-objectl  func¬ 
tion  in  the  prepass. 1  program  to  decompose  always  and 
process  components  into  lists  of  operand  data  structures . 
The  operand  data  structures  are  converted  into  an  extraction 
data  structure.  The  always  and  process  components  are  part 
of  a  design  specification.  The  operand  and  extraction  data 
structures  are  defined  in  the  defstructs.l  program.  The 
four  top  level  functions  in  the  extract. 1  program  that  are 
called  by  the  get-objectl  function  in  prepass. 1  are  get-se- 
quencers-from-component-list ,  get-sequencers-required-def i- 
nitions,  extract-component-list,  and  post-process. 


a.  Get-sequencers-from-component-list 


Get-sequencers-from-component-list  is  a  recur¬ 
sive  function  that  translates  a  list  of  components  into  a 
list  of  sequencer  data  structures.  The  sequencer  data 
structure  is  defined  in  the  defstructs.l  program.  A 
sequencer  is  a  group  of  units  in  the  data  path  that  stores 
and  manipulates  the  state  number  of  a  process13.  The  three 
types  of  sequencers  are  counter-stack,  counter-no-stack,  and 
no-counter-no-stack.  These  types  of  sequencers  and  the  data 
path  components  that  support  them  are  listed  in  Table  3.2. 


TABLE  3.2  SEQUENCER  TYPES 


Counter- 

Stack 

Counter- 

No-Stack 

No-Counter- 

No-Stack 

internal  port 

yes 

yes 

yes 

state  register 

yes 

yes 

yes 

incrementer 

yes 

yes 

no 

LIFO  stack 

yes 

no 

no 

(1)  No-Counter-No-Stack.  The  no-counter-no- 
stack  sequencer  is  the  simplest  sequencer.  The  layout  of 
the  sequencer,  produced  by  the  layout-data-path  def symbol  in 
the  data-path.l  program,  includes  a  register  unit,  an 


1  O  #  , 

For  a  discussion  of  processes  and  state  numbers,  see 
Paragraph  II.D. 


internal  port  unit,  and  a  bit  unit14.  This  type  of 
sequencer  is  used  for  processes  that  use  explicit  go  state¬ 
ments  for  all  state  transitions.  The  following  process  def¬ 
inition  from  a  design  specification  has  two  states  and  uses 
explicit  go  statements.  It  requires  a  no-counter-no-stack 
sequencer . 

(process  ncns  0 
statel 

(par  (setq  a  b)  (go  state2)) 

state2 

(par  (setq  b  c)  (go  statel))) 

(2)  Counter-No-Stack .  The  counter-no-stack 
sequencer  is  used  for  processes  that  do  not  use  call  and 
return  statements  and  do  not  have  explicit  go  statements  for 
all  state  transitions.  The  layout  of  the  sequencer,  pro¬ 
duced  by  the  layout-data-path  def symbol  in  the  data-path.l 
program,  includes  an  incrementer  type  (1+)  organelle  unit  in 
addition  to  the  units  used  in  a  no-counter-no-stack 
sequencer.  The  following  process  definition  from  a  design 
specification  has  two  states  and  does  not  use  call,  return, 
or  explicit  go  statements. 

(process  cns  0 
(setq  a  b) 

(setq  b  c) ) 

(3)  Counter-Stack.  The  counter-stack  sequencer 
is  used  for  processes  that  contain  call  and  return 

14For  a  description  of  the  operation  of  the  units  in  a 
sequencer,  see  Paragraph  V.B.l.a. 
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statements.  The  layout  of  the  sequencer,  produced  by  the 
layout-data-path  defsymbol  in  the  data-path.l  program,  in¬ 
cludes  additional  register  units  in  addition  to  the  units 
used  in  a  no-counter-no-stack  sequencer.  The  following 
process  definition  from  a  design  specification  has  five 
states  and  uses  call  and  return  statements.  The  third  ele¬ 
ment  of  the  process  definition  specifies  a  stack  depth  of 
one  so  a  single  additional  register  unit  is  added  by  layout- 
data-path  . 

(process  cs  l 
main 

(setq  a  b) 

(call  sub) 

(go  main) 

sub 

(setq  b  c) 

(return) ) 

b.  Get-sequencers-required-definitions 

The  get-sequencers-required-def initions  function 
returns  a  list  of  register,  internal  port  and  signal, 
source,  and  destination  definitions  for  the  sequencers  pro¬ 
duced  by  the  get-sequencers-from-component-list  function. 
Tables  3.3,  3.4,  and  3.5  list  the  definitions  generated  for 
each  type  of  sequencer.  At  execution  time,  procname  in 
these  tables  is  replaced  by  the  process  name  assigned  in  a 
design  specification.  A  counter-stack  sequencer  requires 
definitions  for  a  state  register,  internal  go,  call,  and 
return  signals,  and  a  next-state  internal  port.  In  addi¬ 
tion,  a  register  definition  is  required  for  each  level  of 


TABLE  3.3  COUNTER-STACK  SEQUENCER  DEFINITIONS 


Definition  Type 

Definition  Name 

register 

sequencer-procname-state 

source 

sequencer-procname-state 

destination 

sequencer-procname-state 

internal  signal 

sequencer-procname-go 

source 

sequencer-procname-go 

destination 

sequencer-procname-go 

internal  signal 

sequencer-procname-call 

source 

sequencer-pr ocname-cal 1 

destination 

sequencer-procname-cal 1 

internal  signal 

sequencer-procname-return 

source 

sequencer-procname-return 

destination 

seguencer-procname-return 

internal  port 

sequencer-procname-next-state 

source 

sequencer-procname-next-state 

destination 

sequencer-procname-next-state 

register 

sequencer-procname-stack-# 

source 

sequencer-procname-stack-# 

destination 

sequencer-procname-stack-# 

Note:  The  last  three  entries  are  repeated  for  each 
level  of  the  LIFO  stack  with  #  replaced  by 
the  stack  level. 


t 
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TABLE  3.4  COUNTER-NO -STACK  SEQUENCER  DEFINITIONS 


Definition  Type 

Definition  Name 

register 

sequencer-procname-state 

source 

sequencer-procname-state 

destination 

sequencer-procname-state 

internal  signal 

sequencer-procname-go 

source 

sequencer-procname-go 

destination 

sequencer-procname-go 

internal  port 

sequencer-procname-next-state 

source 

sequencer-procname-next-state 

destination 

sequencer-procname-next-state 

TABLE  3.5  NO-COUNTER-NO-STACK  SEQUENCER  DEFINITIONS 


Definition  Type 

Definition  Name 

register 

sequencer-procname-state 

source 

sequencer-procname-state 

destination 

sequencer-procname-state 

internal  port 

sequencer-procname-next-state 

source 

sequencer-procname-next-state 

destination 

sequencer-procname-next-state 

the  LIFO  stack.  A  counter-no-stack  sequencer  requires  defi¬ 
nitions  for  a  state  register,  internal  go  signal,  and  a 
next-state  internal  port.  A  no-counter-no-stack  sequencer 


requires  definitions  for  a  state  register  and  a  next-state 
internal  port.  All  sequencers  also  require  source  and 
destination  definitions  for  all  registers,  ports  and 
signals.  A  source  definition  indicates  that  a  data  primi¬ 
tive  is  used  to  provide  a  value.  A  destination  definition 
indicates  that  a  data  primitive  is  assigned  a  value. 

c.  Extract-component-list 

The  extract-component  function  converts  a 
component-list  into  an  extraction  data  structure.  A 
component-list  is  a  list  of  par,  if,  setq,  nor,  bit,  go, 
call,  and  return  components  for  each  process  or  always  in 
the  design  specification.  A  component-list  also  contains 
functions  and  tests  from  the  design  specification.  The  def¬ 
initions  of  valid  functions  and  tests  are  in  the  library 
program.  The  library  program  also  contains  macro  and 
constant  definitions  that  are  used  to  convert  a  design  spec¬ 
ification  into  components.  The  extraction  data  structure  is 
defined  in  the  defstructs.l  program. 

d.  Post-process 

The  post-process  function  expands  and  optimizes 
the  extraction  data  structure.  Each  unit  in  the  data  path 
is  assigned  a  unique  unit  number  by  the  assign-bus-numbers 
function.  Units  are  the  word  sized  building  blocks  of  the 
data  path.  The  five  types  of  units  are  register,  output 
port,  internal  port,  bit,  and  organelle.  Units  include 
multiplexers  that  are  connected  to  the  control  logic  array. 


The  multiplexers  determine  the  input  sources  of  the  units. 
If  the  opt-d  (data  path  optimization)  command  line  option  is 
selected,  the  order  function  in  the  order. 1  program  is  used 
to  optimize  the  order  of  the  units  in  the  data  path  to  mini¬ 
mize  the  number  of  tracks  in  the  data  path  internal  bus. 
The  columns  in  the  control  logic  array  that  represent 
control  lines,  test  lines,  drive  lines,  bit  lines,  and  arg 
lines  for  the  units  in  the  data  path  are  arranged  to  match 
the  order  of  the  units  in  the  data  path.  These  lines  are 
the  connections  between  the  data  path  and  the  control  logic 
array.  This  completes  the  construction  of  an  extraction 
data  structure. 

11.  Program  order. 1 

Program  order. 1  contains  the  top  level  order  func¬ 
tion  that  is  used  to  optimize  the  placement  of  units  in  the 
data  path  and  gates  in  the  control  logic  array.  The  order 
function  is  called  by  the  post-process  function  in  extract. 1 
to  optimize  the  placement  of  units  in  the  data  path  to  re¬ 
duce  the  number  of  tracks  in  the  data  path  internal  bus. 
The  order  function  is  called  by  the  layout-object  function 
in  frame. 1  to  optimize  gate  placement  to  reduce  the  number 
of  tracks  in  the  control  logic  array.  Command  line  options 
beginning  with  "opt-”  control  the  operation  of  the  order 
function.  The  opt-d  command  line  option  enables 


optimization  of  unit  placement  in  the  data  path.  The  opt-c 
command  line  option  enables  optimization  of  gate  placement 


in  the  control  logic  array.  The  opt-n  command  line  option 
disables  the  restriction  that  the  order  of  columns  in  the 


control  logic  array  must  match  the  order  of  control  lines, 
test  lines,  drive  lines,  bit  lines,  and  arg  lines  for  the 
units  in  the  data  path.  The  opt-n  command  line  option 
should  not  be  used  with  the  current  method  of  connecting  the 
data  path  to  the  control  logic  array.  The  opt-n  command 
line  option  may  be  used  in  the  future  if  a  method  of  con¬ 
necting  the  control  logic  array  to  the  data  path  that  allows 
crossing  of  runs  is  added  to  MSC.  The  opt-p  command  line 
option  enables  printing  of  the  current  permutation  and 
optimization  status  messages  on  the  terminal.  The  opt-s 
command  line  option  enables  printing  of  a  list  of  segments 
after  the  current  permutation  of  the  opt-p  command  line  op¬ 
tion.  The  opt-s  command  line  option  is  inactive  if  the  opt- 
p  command  line  option  is  not  specified.  There  are  debugging 
functions  named  opt,  order-this,  this-node-column,  and  this- 
segment-nodes  that  demonstrate  the  operation  of  the  order 
function. 

12 .  Program  frame . 1 

The  frame. 1  program  contains  the  top  level  function 
layout-object  that  is  called  by  the  macpitts-compiler  func¬ 
tion  in  prepass. 1.  The  layout-object  function  converts  an 
object  data  structure  into  an  L5  item  data  structure.  The 
item  is  converted  into  a  CIF  file  by  the  cifout  function  in 
L5.1.  The  top  level  of  the  hierarchical  item  contains 


juim  iu  wmiwi  tu»  m  ujiii  uimvimu  jriiw  ■  m  in  ui  ■»  m  znrrwawvtnnnnrraa 


connections  between  the  pads,  data  path,  and  control  logic 
array,  a  set  of  L5  symbols  that  contain  the  lower  level 
structures  of  the  layout,  and  marks  associated  with  the 
names  of  the  pad  signals.  The  lower  level  symbols  are  named 
layout-data-path,  layout-control,  layout-flags,  layout-wing, 
layout-skeleton,  and  layout-pins.  All  symbols  are  created 
using  the  defsymbol  macro  in  L5.1.  The  def symbol  defini¬ 
tions  for  layout -wing,  layout-skeleton,  and  layout-pins  are 
in  frame. 1.  The  defsymbol  definition  for  layout-data-path 
is  in  data-path.l,  the  defsymbol  definition  for  layout-con¬ 
trol  is  in  control. 1,  and  the  defsymbol  definition  for 
layout-flags  is  in  flags. 1. 

13 .  Program  data-path.l 

The  data-path.l  program  contains  the  L5  defsymbol 
macro  definition  for  the  layout-data-path  symbol.  The 
layout-data-path  defsymbol  is  called  by  the  layout-object 
function  in  frame.  1.  The  top  level  of  the  L5  item  data 
structure  returned  by  layout-data-path  contains  all  of  the 
data  path  internal  buses  and  a  layout-unit  symbol  for  each 
unit  in  the  data  path.  Units  are  the  word  sized  building 
blocks  of  the  data  path.  The  five  types  of  units  are 
register,  output  port,  internal  port,  bit,  and  organelle15. 
Units  include  multiplexers  that  are  connected  to  the  control 
logic  array.  The  multiplexers  determine  the  input  sources 


15For  a  description  of  units,  see  Paragraph  II. A. 1 
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of  the  units.  The  layout  for  all  units  in  the  data  path  is 
performed  by  the  layout-unit  function  in  data-path.l.  The 
layout-unit  function  calls  the  layout-organelle  function  in 
data-path.l  to  build  each  bit  of  the  unit.  The  layout-or¬ 
ganelle  function  calls  the  lookup-gen- form  function  in 
general.  1  to  find  the  layout  of  an  organelle  in  the  unit. 
The  layout-organelle  function  then  calls  the  layout-mpx 
function  to  layout  the  multiplexer,  the  layout-gen-form 
function  to  instantiate  (generate  an  instance  of)  the  layout 
of  the  organelle,  and  the  river  function  in  general. 1  to 
layout  the  data  path  internal  bus.  The  functions  that  are 
called  by  the  layout-mpx  function  generate  four  types  of 
multiplexers:  layout-mpxO,  layout-mpxl,  layout-mpx2 ,  and 
layout-mpx3 .  The  layout-mpxO  multiplexer  has  no  constant 
(wired)  inputs,  the  layout-mpxl  multiplexer  has  logical  one 
constant  (wired)  inputs,  the  layout-mpx2  multiplexer  has 
logical  zero  constant  (wired)  inputs,  and  the  layout-mpx3 
multiplexer  has  both  logical  zero  and  logical  one  constant 
(wired)  inputs.  Degenerate  multiplexers  with  single  inputs 
are  produced  by  the  layout-singleton-operand-list  and  the 
layout-mpx  functions.  The  functions  and  def symbols  used  to 
construct  register,  output  port,  internal  port,  and  bit 
organelles  and  multiplexers  are  in  data-path.l.  The  output 
port  and  internal  port  use  the  same  layout-port-output 


function. 


The  control. 1  program  contains  the  top  level  layout- 
control  defsymbol  definition  that  is  called  by  the  layout- 
object  function  in  the  frame. 1  program.  The  layout-control 
defsymbol  returns  a  symbol  containing  the  layout  of  the 
control  logic  array.  The  layout-control  defsymbol  merges 
the  items  returned  by  the  layout-weinberger-gates  function 
and  the  layout-weinberger-straps  defsymbol  to  build  the 
control  logic  array. 

15.  Program  flags . 1 

The  flags. 1  program  contains  the  top  level  layout- 
flags  defsymbol  definition.  The  layout-flags  defsymbol  is 
called  by  the  layout-object  function  in  the  frame. 1  program. 
Layout-flags  returns  a  symbol  item  containing  the  registers 
for  single  bit  data. 

16.  Program  pads.l 

The  pads.l  program  is  generated  by  the  padgen.l  pro¬ 
gram.  Pads.l  contains  layout  functions  and  def symbols  for 
all  of  the  pad  connections.  The  pads.l  layout  functions  are 
called  by  the  layout-pad  function  in  frame. 1.  Since  the 
pads.l  program  is  machine  generated,  the  file  is  deleted  by 
the  make  clean  Makefile  command.  The  make  pads.l,  make 


pads. o,  make  macpitts,  and  make  Macpitts  Makefile  commands 
cause  the  pads.l  program  to  be  generated. 


The  padgen.l  program  contains  the  top  level  main 
function  that  generates  the  pads.l  program.  The  main  func¬ 
tion  uses  the  read-cif  function  to  read  the  pad20b  and 
rinout  pad  CIF  files. 

b.  Pad  File  pad20b 

The  pad20b  pad  CIF  file  contains  CIF  descrip¬ 
tions  of  the  layout  of  four  micron  minimum  feature  size  nMOS 
pads.  This  file  is  read  by  the  read-cif  function  in  the 
padgen.l  program.  The  information  in  pad20b  is  used  to  gen¬ 
erate  the  pads . 1  program . 

c.  Pad  File  rinout 

The  rinout  pad  CIF  file  contains  CIF  descrip¬ 
tions  of  the  layout  of  five  micron  minimum  feature  size  nMOS 
pads.  This  file  is  read  by  the  read-cif  function  in  the 
padgen.l  program.  The  information  in  rinout  is  used  to  gen¬ 
erate  the  pads.l  program. 

17 .  Program  interpret . 1 

The  interpret. 1  program  contains  the  top  level 
interpret  function  that  is  called  by  the  macpitts-compiler 
function  in  prepass. 1  to  perform  a  functional  simulation  of 
a  design  specification.  The  interpret  function  uses  many  of 
the  same  functions  in  the  prepass. 1  and  general. 1  programs 
that  the  macpitts-compiler  function  uses  to  get  information 
from  the  design  specification  and  library  files.  The 


function  and  test  definitions  in  the  library  program  are 


also  used  in  the  functional  simulation  of  a  design  speci¬ 
fication.  The  curses  terminal  screen  updating  and  cursor 
movement  optimization  package  functions  in  the  c-routines.c 
program  are  used  to  display  the  results  of  the  functional 
simulation  on  the  terminal. 

18.  Makefile 

The  Makefile  is  used  to  generate  the  MSC  compiler 
and  maintain  the  files  in  the  macpit  directory.  The 
Makefile  uses  the  UNIX  make  facility  to  generate  a  program 
that  is  current  with  respect  to  the  sources  that  are  used  to 
generate  the  program.  If  the  program  is  current,  the  make 
commands  do  nothing.  The  Makefile  contains  commands  to  make 
the  c-routines.o,  lincoln.l,  L5.o,  defstructs.o,  prepass. o, 
extract. o,  frame. o,  data-path.o,  control. o,  flags. o, 
padgen.o,  pads.o,  order. o,  general. o,  interpret. o,  and 
organelles. o  object  files  and  the  pads.l  machine  generated 
Lisp  file.  The  make  macpitts  command  generates  an  exe¬ 
cutable  version  of  the  MSC  compiler  with  the  name  macpitts. 
The  make  Macpitts  command  installs  the  macpitts  file  with 
the  name  Macpitts  on  all  three  ISI  workstations.  The  make 
Macpitts  command  also  copies  the  current  library  and 
organelles. o  files  from  the  ISIO  workstation  to  the  ISI1  and 
ISI2  workstations.  The  make  xref  command  generates  and 
prints  a  cross  reference  file  named  xref  for  the  MSC  com¬ 
piler.  The  make  clean  command  removes  all  excess  files  from 


the  macpit  directory  on  the  ISIO  workstation.  The  make  doc 
command  prints  all  documentation  and  sources. 

E.  MSC  INTERNAL  STRUCTURE  REQUIREMENTS 

The  MSC  internal  structure  implies  required  characteris¬ 
tics  of  a  controller.  The  controller  must  be  constructed 
from  hierarchical  components.  The  combination  of  these  com¬ 
ponents  must  be  easily  derived  from  an  extraction  or  object 
data  structure.  The  building  blocks  should  be  technology 
independent  so  that  the  same  program  can  be  used  with  dif¬ 
ferent  technologies.  The  software  to  produce  the  controller 
must  be  able  to  replace  the  corresponding  programs  and  func¬ 
tions  in  the  current  nMOS  MSC.  These  requirements  will  be 
used  to  evaluate  the  suitability  of  controller  designs. 


"Goals  are  targets  for  achievement,  and  serve  to  estab¬ 
lish  the  framework  for  a  software  development  project"  and 
"Requirements  specify  capabilities  that  a  system  must  pro¬ 
vide  in  order  to  solve  a  problem. " (Fairley,  1985,  pp.  32, 
33)  It  is  crucial  that  goals  and  requirements  be  estab¬ 
lished  in  the  analysis  phase  of  a  project  before  entering 
the  design  phase.  In  the  design  phase,  goals  are  used  to 
evaluate  alternative  design  decisions  and  requirements  are 
used  to  reject  alternatives  that  will  not  solve  the  problem. 
In  the  implementation  phase,  the  goals  provide  direction  for 
construction  of  the  structures  specified  in  the  design.  In 
the  testing  phase,  the  requirements  provide  the  acceptance 
criteria  used  to  validate  the  performance  of  the  system. 
The  goals  for  this  controller  design  are  derived  from  the 
goals  of  the  MSC  development  project  and  the  requirements 
are  based  on  the  analysis  performed  in  Chapters  II  and  III. 

A.  MSC  CONTROLLER  GOALS 

T1  e  primary  goal  of  the  MSC  development  project  is  to 
produce  a  version  of  MSC  that  is  capable  of  producing  an 
SCMOS  VLSI  circuit.  An  extension  of  this  goal  is  to  produce 
a  silicon  compiler  that  is  capable  of  producing  a  VLSI  cir¬ 
cuit  in  any  existing  or  future  technology.  MSC  should  be 
designed  for  easy  addition  of  new  technologies.  As  much  of 


the  system  as  possible  should  be  technology  independent. 
Technology  dependent  functions  should  be  confined  to  the 
library  and  organelles. o  programs  that  are  loaded  at  run 
time.  The  SCMOS  version  of  MSC  should  produce  layouts  that 
are  compact  and  fast.  Growth  of  the  size  of  a  layout  should 
be  a  linear  function  of  the  complexity  of  the  design  speci¬ 
fication  for  the  layout.  Geometric  or  exponential  growth  is 
to  be  avoided.  Module  interconnections  should  be  simple. 
Modules  should  interconnect  by  abutting  or  overlapping  when¬ 
ever  possible.  The  MOS  transistors  should  be  operated  in 
the  saturation  or  cutoff  modes  to  reduce  power  consumption. 
Resistive  pull  up  structures  are  to  be  avoided.  Substrate 
and  well  contacts  should  be  used  in  every  cell  to  reduce  the 
possibility  of  latch  up.  Long  wiring  runs,  especially  in 
polysilicon,  are  to  be  avoided.  The  purpose  of  these  goals 
is  to  produce  VLSI  circuits  that  are  small,  fast,  and 
efficient. 

B.  MSC  CONTROLLER  REQUIREMENTS 

The  MSC  controller  requirements  are  the  results  of  the 
analysis  in  Chapters  II  and  III  of  the  target  architecture 
and  internal  structure  of  MSC.  To  become  part  of  a  SCMOS 
silicon  compiler,  the  controller  must  satisfy  all  of  these 
requirements.  The  controller  must  be  composed  of  multiple 
Mealy  FSMs  that  have  a  single  state  number  state  variable 
and  may  include  an  incrementer  and  subroutine  stack.  Units 


in  the  data  path  are  controlled  by  single  FSMs  using  true 
multiplexers  that  have  no  side  effects.  All  effects  of 
multiplexer  selection  must  be  local  to  the  output  of  the 
multiplexer  and  not  global  to  the  entire  circuit.  These 
FSMs  must  be  constructed  from  hierarchical  components  and  be 
easily  derived  from  an  extraction  or  object  data  structure. 
The  software  to  produce  the  controller  must  be  able  to  re¬ 
place  the  corresponding  programs  and  functions  in  the  cur¬ 
rent  nMOS  MSC.  These  requirements  will  be  used  to  eliminate 
design  alternatives  that  do  not  satisfy  the  requirements  and 
to  validate  the  final  controller  implementation. 
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ARCHITECTURE  TRADE-OFF  STUDIES 


The  architecture  trade-off  studies  are  the  start  of  the 
design  phase  of  the  controller  development.  In  this  first 
part  of  the  design  phase,  different  SCMOS  logic  structures 
and  organizations1  are  evaluated  to  determine  which  are  ca¬ 
pable  of  fulfilling  the  controller  requirements.  After  the 
structures  and  organizations  that  cannot  meet  the 
requirements  are  eliminated,  those  remaining  are  evaluated 
using  the  controller  goals  to  determine  which  structure  and 
organization  have  the  greatest  compliance  with  the  goals. 
These  are  the  structure  and  organization  that  will  be  used 
for  the  controller.  The  SCMOS  logic  structures  that  are 
evaluated  are  static  CMOS  complementary  logic,  pseudo-nMOS 
logic,  dynamic  CMOS  logic,  clocked  CMOS  logic,  CMOS  domino 
logic,  cascade  voltage  switch  logic,  modified  domino  logic, 
and  transmission  gate  logic.  The  SCMOS  organizations  that 
are  evaluated  are  standard  cells,  programmable  logic  arrays 
(PLAs) ,  Weinberger  arrays,  and  microprogram  read  only  memory 
(ROM)  . 


1For  a  complete  description  of  CMOS  logic  structures  and 
organizations,  see  Chapters  5  and  8  in  Principles  of  CMOS 
VLSI  Design (Weste  and  Eshraghian,  pp.  160-189  and  310-378, 
1985)  . 


A.  LOGIC  STRUCTURE  TRADE-OFF  STUDIES 


The  logic  structure  trade-off  studies  start  with  a 
requirements  analysis  to  eliminate  structures  that  do  not 
meet  the  requirements.  This  is  followed  by  a  goals  analysis 
to  determine  how  closely  each  structure  conforms  to  the 
controller  goals.  The  structure  with  the  closest  confor¬ 
mance  to  the  goals  is  the  logic  structure  that  will  be  used 
for  the  controller.  All  structures  considered  are  homoge¬ 
neous.  Hybrid  structures  may  be  more  efficient  than  the 
homogeneous  structures  but  the  programs  that  generate  them 
would  be  more  complex  and  circuits  built  of  hybrid  struc¬ 
tures  would  not  be  regular.  Hybrid  structures  would  be  a 
form  of  optimization  that  would  sacrifice  program  maintain¬ 
ability  for  small  gains  in  size  or  speed.  Thus,  hybrid 
structures  will  not  be  used  in  this  controller. 

1.  Structural  Requirements  Analysis 

The  structural  requirements  analysis  examines  each 
structure  and  decides  whether  or  not  the  structure  is  capa¬ 
ble  of  satisfying  the  requirements.  All  structures  that 
cannot  satisfy  the  requirements  are  eliminated  from  further 
evaluation.  The  requirements  used  to  screen  structures  are 
that  the  controller  must  be  a  modified  Mealy  FSM  and  that 
the  controller  must  be  constructed  from  hierarchical  compo¬ 
nents.  Basic  logic  functions  of  a  structure  must  be  easily 
cascaded  or  connected  to  form  more  complex  logic  functions 
in  a  hierarchical  design. 


a.  Static  CMOS  Complementary  Logic 


Static  CMOS  complementary  logic  uses  active  pull 
up  and  pull  down  structures  that  are  duals  of  each  other. 
The  pull  up  structure  is  composed  of  p-type  transistors  and 
the  pull  down  structure  is  composed  of  n-type  transistors. 
The  duals  of  pull  down  structures  connected  in  parallel  are 
pull  up  structures  connected  in  series  and  the  duals  of  se¬ 
ries  pull  down  structures  are  parallel  pull  up  structures. 
An  example  of  a  static  CMOS  complementary  logic  gate  is  in 
Figure  5.1.  The  output  of  this  gate  is  the  function  (NOT 
( (A  AND  B)  OR  C) )  .  The  gate  has  twice  as  many  transistors 
as  there  are  inputs  to  the  gate.  The  output  is  continuously 
responsive  to  changes  in  the  inputs.  This  structure  can  be 
used  to  build  a  Mealy  FSM.  Basic  logic  functions  of  static 
CMOS  complementary  logic  are  easily  cascaded  or  connected  to 
form  more  complex  logic  functions  in  a  hierarchical  design. 
Static  CMOS  complementary  logic  is  capable  of  satisfying  all 
design  requirements. 

b.  Pseudo-nMOS  Logic 

The  pseudo-nMOS  logic  is  similar  to  normal  nMOS 
logic.  The  only  difference  is  that  the  depletion  mode 
n-type  pull  up  transistor  in  nMOS  is  replaced  by  an  en¬ 
hancement  mode  p-type  pull  up  transistor  in  pseudo-nMOS.  An 
example  of  a  pseudo-nMOS  logic  gate  is  in  Figure  5.2.  The 
output  of  this  gate  is  the  function  (NOT  ( (A  AND  B)  OR  C) ) . 
The  gate  has  one  more  transistor  than  there  are  inputs 
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Figure  5 . 1  Static  CMOS  Complementary  Logic 


to  the  gate.  This  savings  in  the  number  of  transistors  is 
the  result  of  eliminating  the  pull  up  structure  that  is  the 
dual  of  the  pull  down  structure  in  static  CMOS 
complementary  logic.  The  output  is  continuously  responsive 
to  changes  in  the  inputs.  The  gate  draws  power  whenever  the 
pull  down  is  active.  This  structure  can  be  used  to  build  a 
Mealy  FSM.  Basic  logic  functions  of  pseudo-nMOS  logic  are 
easily  cascaded  or  connected  to  form  more  complex  logic 
functions  in  a  hierarchical  design.  Pseudo-nMOS  logic  is 
capable  of  satisfying  all  design  requirements. 


Figure  5.2  Pseudo-nMOS  Logic 
c.  Dynamic  CMOS  Logic 

Dynamic  CMOS  logic  combines  the  simplicity  of 
pseudo-nMOS  with  reduced  power  consumption.  This  structure 
takes  advantage  of  the  capacitance  in  the  output  node  of  the 
gate.  Under  control  of  a  clock,  the  output  node  is  alter¬ 
nately  precharged  to  one  and  conditionally  discharged  to 
zero.  If  the  logic  function  of  the  pull  down  structure 
is  satisfied,  the  output  node  is  pulled  down  to  zero  during 
the  evaluation  phase  of  the  clock.  If  the  logic  function  of 
the  pull  down  structure  is  not  satisfied,  the  output  node 
remains  a  logic  one  during  the  evaluation  phase  of  the 
clock.  An  example  of  a  dynamic  CMOS  logic  gate  is  in  Figure 
5.3.  The  output  of  this  gate  is  the  function  (NOT  ((A  AND 


Figure  5.3  Dynamic  CMOS  Logic 

B)  OR  C) ) .  The  gate  has  two  more  transistors  than  there  are 
inputs  to  the  gate.  Dynamic  CMOS  gates  are  not  easily  cas¬ 
caded.  To  reliably  connect  cascaded  dynamic  CMOS  gate  out¬ 
puts  to  other  dynamic  CMOS  gate  inputs  requires  transmission 
gates  and  four  phase  clocking.  One  v-lock  phase  of  delay 
from  input  to  output  is  encountered  for  each  level  of  logic. 
The  output  is  not  continuously  responsive  to  changes  in  the 
inputs.  During  precharge,  the  output  is  independent  of  the 
input.  During  evaluation,  the  output  may  transition  from 
one  to  zero  if  the  pull  down  logic  becomes  satisfied.  The 
output  may  not  transition  from  zero  to  one  during 


evaluation.  This  structure  can  be  used  to  build  a  Moore 
FSM.  This  FSM  would  have  a  complicated  clock  cycle  that  may 
include  several  cycles  of  a  four  phase  clock  for  every  state 
transition.  The  dynamic  CMOS  logic  could  not  be  used  to 
build  a  Mealy  FSM.  Basic  logic  functions  of  dynamic  CMOS 
logic  are  not  easily  cascaded  or  connected  to  form  more  com¬ 
plex  logic  functions  in  a  hierarchical  design.  Dynamic  CMOS 
logic  is  not  capable  of  satisfying  all  design  requirements, 
d.  Clocked  CMOS  Logic 

Clocked  CMOS  logic  is  static  CMOS  complementary 
logic  with  a  clocked  transmission  gate  added  to  the  output. 
An  example  of  a  clocked  CMOS  logic  gate  is  in  Figure  5.4. 
The  output  of  this  gate  is  the  function  (NOT  ( (A  AND  B)  OR 
C) )  .  The  gate  has  two  more  transistors  than  two  times  the 
number  of  inputs  to  the  gate.  Clocked  CMOS  logic  is  more 
complex  and  slower  than  static  CMOS  complementary  logic. 
The  output  of  the  gate  is  not  responsive  to  the  input  to  the 
gate  when  the  clock  is  zero.  Clocked  CMOS  logic  could  be 
used  to  build  a  Moore  FSM  but  not  a  Mealy  FSM.  Basic  logic 
functions  of  clocked  CMOS  logic  are  easily  cascaded  or  con¬ 
nected  to  form  more  complex  logic  functions  in  a  hierarchi¬ 
cal  design.  Clocked  CMOS  logic  is  not  capable  of  satisfying 
all  design  requirements. 


H 


Figure  5.4  Clocked  CMOS  Logic 


e.  CMOS  Domino  Logic 

CMOS  domino  logic  gates  are  dynamic  CMOS  logic 
gates  with  static  CMOS  complementary  logic  inverters  on  the 
output.  By  inverting  the  output  of  each  gate,  CMOS  domino 
logic  gates  can  be  easily  connected  in  cascade  configura¬ 
tions.  An  example  of  a  CMOS  domino  logic  gate  is  in  Figure 
5.5.  The  output  of  this  gate  is  the  function  ((A  AND  B)  OR 
C)  .  The  gate  has  four  more  transistors  than  there  are 
inputs  to  the  gate.  The  output  is  not  continuously 


69 


»fc  *1-  ill .1  ti-  **.  }\ t  j,«  i,«  J* 


*  "If, |  *»i  ?.» 


Clock 


Figure  5.5  CMOS  Domino  Logic 


responsive  to  changes  in  the  inputs.  During  precharge,  the 
output  is  independent  of  the  input.  During  evaluation,  the 
output  may  transition  from  zero  to  one  if  the  pull  down 
logic  becomes  satisfied.  The  output  may  not  transition  from 
one  to  zero  during  evaluation.  This  structure  can  be  used 
to  build  a  Moore  FSM.  The  CMOS  domino  logic  could  not  be 
used  to  build  a  Mealy  FSM.  Basic  logic  functions  of  CMOS 
domino  logic  are  easily  cascaded  or  connected  to  form  more 
complex  logic  functions  in  a  hierarchical  design.  CMOS 
domino  logic  is  not  capable  of  satisfying  all  design 
requirements . 


f.  Cascade  Voltage  Switch  Logic 

Cascade  voltage  switch  logic  requires  complemen¬ 
tary  inputs  and  produces  complementary  outputs.  Each  gate 
uses  two  n-type  pull  down  structures  that  are  the  duals  of 
each  other.  The  output  of  each  pull  down  structure  is  con¬ 
nected  to  the  gate  of  a  single  p-type  pull  up  transistor  for 
the  other  output.  This  form  of  cascade  voltage  switch  logic 
is  slower  than  static  CMOS  complementary  logic.  For  a  short 
time  during  switching,  the  pull  up  and  pull  down  structures 
for  one  of  the  outputs  are  both  active.  An  example  of  a 
cascade  voltage  switch  logic  gate  is  in  Figure  5.6.  The 
output  of  this  gate  is  the  function  (NOT  ( (A  AND  B)  OR  C) )  . 
The  gate  has  two  more  transistors  than  twice  the  number  of 
inputs  to  the  gate.  The  output  does  respond  continuously  to 
changes  in  the  input  signals.  A  more  efficient  version  of 
cascade  voltage  switch  logic  is  clocked  with  precharge  and 
evaluate  transistors  similar  to  dynamic  CMOS  logic  on  each 
pull  down  structure  and  inverters  on  each  output  like  CMOS 
domino  logic.  The  outputs  of  the  clocked  cascade  voltage 
switch  logic  gates  are  not  continuously  responsive  to 
changes  in  the  inputs.  During  precharge,  the  outputs  are 
independent  of  the  inputs.  During  evaluation,  the  outputs 
may  transition  from  zero  to  one  if  their  pull  down  logic  be¬ 
comes  satisfied.  The  outputs  may  not  transition  from  one  to 
zero  during  evaluation.  The  static  version  of  cascade  volt¬ 
age  switch  logic  could  be  used  to  construct  a  Moore  or 


Figure  5.6  Cascade  Voltage  Switch  Logic 


Mealy  FSM.  The  clocked  version  of  cascade  voltage  switch 
logic  could  be  used  to  construct  a  Moore  FSM  but  not  a  Mealy 
FSM.  Basic  logic  functions  of  cascade  voltage  switch  logic 
are  easily  cascaded  or  connected  to  form  more  complex  logic 
functions  in  a  hierarchical  design.  The  static  version  of 
cascade  voltage  switch  logic  can  satisfy  the  controller 
requirements  and  the  clocked  version  of  cascade  voltage 
switch  logic  cannot  satisfy  the  controller  requirements, 
g.  Modified  Domino  Logic 

Modified  domino  logic  is  an  improvement  on  CMOS 
domino  logic.  In  modified  domino  logic,  cascade  combina¬ 
tions  of  gates  are  composed  of  alternate  p-type  and  n-type 


gates.  The  n-type  gates  are  similar  to  CMOS  domino  logic 
gates  without  the  inverters  on  the  outputs.  The  p-type 
gates  are  made  of  combinations  of  single  n-type  transistors 
to  precharge  the  outputs  to  zero  and  p-transistor  pull  up 
structures  that  are  the  duals  of  the  n-type  structures  for 
the  same  gate  function.  The  clock  for  the  p-type  gates  is 
the  inverse  of  the  clock  for  the  n-type  gates.  By  elimi¬ 
nating  inverter  outputs,  the  layout  of  modified  domino  logic 
is  more  compact  than  CMOS  domino  logic.  The  operation  of 
the  modified  domino  logic  is  similar  to  CMOS  domino  logic. 
Modified  domino  logic  could  be  used  to  construct  a  Moore  FSM 
but  not  a  Mealy  FSM.  Basic  logic  functions  of  modified 
domino  logic  are  easily  cascaded  or  connected  to  form  more 
complex  logic  functions  in  a  hierarchical  design.  Modified 
domino  logic  cannot  meet  the  controller  requirements, 
h.  Transmission  Gate  Logic 

Transmission  gate  logic  uses  combinations  of 
transmission  gates  to  build  logical  functions.  A  CMOS 
transmission  gate  is  a  parallel  connection  of  a  p-type  tran¬ 
sistor  and  an  n-type  transistor.  The  gate  of  the  n-type 
transistor  is  driven  by  the  control  signal  and  the  gate  of 
the  p-type  transistor  is  driven  by  the  complement  of  the 
control  signal.  The  transmission  gate  is  like  an  electronic 
relay  that  conducts  when  the  control  signal  is  a  logic  one 
and  does  not  conduct  when  the  control  signal  is  a  logic 
zero.  Many  logical  functions  may  be  efficiently  implemented 
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using  transmission  gate  logic.  An  implementation  of  an 


exclusive  or  (XOR)  gate  requires  only  two  transmission 


gates.  Some  logical  functions  are  accomplished  more  effi¬ 


ciently  using  other  structures  like  static  CMOS 


complementary  logic.  An  example  of  a  transmission  gate 


logic  gate  is  in  Figure  5.7.  The  output  of  this  gate  is  the 


function  (NOT  ( (A  AND  B)  OR  C) )  .  This  logic  function  is 


realized  using  four  transmission  gates.  Another  representa¬ 


tion  of  the  same  gate  using  discrete  transistors  is  in  Fig¬ 


ure  5.8.  An  n-type  transistor  transmits  a  strong  zero  and  a 


Figure  5.7  Transmission  Gate  Logic 


Figure  5.8  Transmission  Gate  Discrete  Components 


weak  one  and  a  p-type  transistor  transmits  a  strong  one  and 


a  weak  zero.  Transmission  gates  for  constant  inputs  require 


only  the  transistors  that  have  strong  transmission  charac¬ 


teristics  for  the  constant.  Thus,  the  n-type  transistors 


associated  with  constant  one  inputs  and  the  p-type  transis¬ 


tors  associated  with  constant  zero  inputs  are  not  required. 


The  circuit  in  Figure  5.8  may  be  reduced  to  the  circuit  in 


Figure  5.9  by  eliminating  the  transistors  with  weak  trans¬ 


mission  characteristics  for  constant  inputs.  For  this  sam¬ 


ple  circuit,  the  transmission  gate  logic  gate  uses  the  same 


number  of  transistors  as  the  static  CMOS  complementary  logic 
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Figure  5.9  Transmission  Gate  Logic  Reduced  Circuit 

circuit.  The  p-type  transistors  in  the  static  CMOS  version 
may  be  replaced  by  a  single  p-type  precharge  transistor  for 
dynamic  logic.  A  static  version  of  the  gate  using  a  single 
p-type  pull  up  transistor  that  is  driven  by  an  inverter  con¬ 
nected  to  the  output  is  another  variant  of  this  circuit. 
The  size  ratios  of  the  transistors  are  critical  in  the  ver¬ 
sion  of  the  circuit  with  a  pull  up  transistor  and  inverter. 
The  static  variations  of  transmission  gate  logic  could  be 
used  to  construct  a  Mealy  FSM.  The  dynamic  variation  could 
not  be  used  to  construct  a  Mealy  FSM.  Basic  logic  functions 


of  the  full  complementary  form  of  transmission  gate  logic 
are  easily  cascaded  or  connected  to  form  more  complex  logic 
functions  in  a  hierarchical  design  while  the  other  forms  of 
transmission  gate  logic  are  not  easily  cascaded.  The  com¬ 
plementary  transmission  gate  logic  can  satisfy  controller 
requirements  while  the  dynamic  transmission  gate  logic  can¬ 
not  satisfy  the  requirements. 

i.  Acceptable  Structures 

The  structures  that  are  capable  of  satisfying 
the  controller  requirements  are  static  CMOS  complementary 
logic,  pseudo-nMOS  logic,  the  static  version  of  cascade 
voltage  switch  logic,  and  the  static  versions  of 
transmission  gate  logic.  These  are  all  structures  that  can 
be  used  to  construct  Mealy  FSMs. 

2 .  Structural  Goals  Analysis 

The  logic  structures  that  remain  after  requirements 
analysis  are  next  examined  to  determine  how  closely  each 
structure  conforms  to  the  controller  goals.  The  structure 
that  is  nearest  to  the  controller  goals  is  selected  for  im¬ 
plementation  of  the  controller. 

a.  Static  CMOS  Complementary  Logic 

The  goals  that  are  closely  satisfied  by  static 
CMOS  complementary  logic  are  high  speed,  low  power,  and  sim¬ 
ple  interconnection.  High  speed  is  obtained  by  active  pull 
up  and  pull  down  structures.  Low  power  results  from  all 


transistors  being  operated  in  the  saturation  or  cutoff 


modes.  Simple  interconnection  is  achieved  since 
complementary  signals  are  not  required.  The  goal  that  is 
not  closely  satisfied  by  static  CMOS  complementary  logic  is 
size.  The  medium  size  of  static  CMOS  complementary  logic  is 
the  result  of  the  dual  pull  up  and  pull  down  structures. 

b.  Pseudo-nMOS  Logic 

The  goals  that  are  closely  satisfied  by  pseudo- 
nMOS  logic  are  size  and  simple  interconnection.  The  small 
size  is  the  result  of  the  single  p-type  transistor  for  the 
pull  up  of  each  gate.  Simple  interconnection  is  achieved 
since  complementary  signals  are  not  required.  The  goals 
that  are  not  satisfied  by  pseudo-nMOS  logic  are  low  power 
and  high  speed.  The  pull  up  structure  that  is  active  when 
the  pull  down  structure  is  in  saturation  causes  high  power. 
For  proper  operation,  the  pull  up  transistors  must  be  weak 
compared  to  the  pull  down  transistors.  This  results  in  slow 
rise  times  for  the  outputs  of  gates.  The  slow  rise  times 
reduce  the  speed  of  the  circuit. 

c.  Static  Cascade  Voltage  Switch  Logic 

The  only  goal  satisfied  by  static  cascade  volt¬ 
age  switch  logic  is  low  power.  Even  the  low  power  is  not  as 
good  as  that  obtained  using  static  CMOS  complementary  logic 
and  complementary  transmission  gate  logic.  The  transistors 
are  in  the  active  mode  during  the  contention  period  that  is 
part  of  switching.  The  goals  that  are  not  satisfied  by 
static  cascade  voltage  switch  logic  are  small  size,  high 


speed,  and  ease  of  interconnection.  Cascade  voltage  switch 
logic  circuits  use  more  transistors  than  static  CMOS 
complementary  logic  circuits.  The  speed  of  cascade  voltage 
switch  logic  is  reduced  by  the  contention  period  that  is 
part  of  switching.  Cascade  voltage  switch  logic  circuits 
require  complementary  inputs  that  result  in  more  complex  in¬ 
terconnections  . 

d.  Complementary  Transmission  Gate  Logic 

The  goals  that  are  closely  satisfied  by  comple¬ 
mentary  transmission  gate  logic  are  small  size,  low  power, 
and  high  speed.  The  size  of  complementary  transmission  gate 
logic  circuits  ranges  from  the  same  size  as  static  CMOS 
complementary  logic  to  smaller  than  pseudo-nMOS  depending  on 
the  circuit  logic  function.  The  power  consumption  is  almost 
as  low  as  static  CMOS  complementary  logic  and  the  speed  is 
almost  as  fast.  The  slightly  slower  speed  and  slightly 
higher  power  are  the  result  of  more  capacitance  in  the  in¬ 
creased  number  of  connections  between  the  pull  up  and  pull 
down  regions  and  the  greater  number  of  separate  source  and 
drain  regions.  In  static  CMOS  complementary  logic,  transis¬ 
tors  of  the  same  type  that  are  connected  in  series  may  have 
their  common  source  and  drain  nodes  merged  together  and 
transistors  connected  in  parallel  may  merge  their  sources  or 
drains.  This  significantly  reduces  the  total  node 
capacitance.  It  is  very  difficult  to  merge  sources  or 
drains  in  complementary  transmission  gate  logic  circuits. 


The  goal  that  is  not  supported  by  complementary  transmission 
gate  logic  is  simple  interconnection.  Complementary 
transmission  gate  logic  circuits  require  complementary  in¬ 
puts  that  result  in  more  complex  interconnections. 

3 .  Structure  Selection 

The  structure  that  satisfies  all  requirements  and 
comes  closest  to  satisfying  all  goals  is  static  CMOS 
complementary  logic.  This  structure  will  be  used  to  imple¬ 
ment  the  controller. 

B.  LOGIC  ORGANIZATION  TRADE-OFF  STUDIES 

There  are  two  organizational  design  decisions  that  yield 
four  possible  organizations  for  the  controller.  The  first 
design  decision  is  whether  or  not  to  use  data  path 
organelles  with  similar  functions  to  the  organelles  used  in 
the  nMOS  version  of  MSC.  The  second  design  decision  is 
whether  to  use  standard  cells  or  a  microprogram  read  only 
memory  (ROM)  for  the  MSC  FSM  combinational  logic. 
Programmable  logic  arrays  (PLAs)  and  Weinberger  arrays  are 
rejected  since  they  cannot  be  easily  implemented  using  the 
static  CMOS  complementary  logic  structure.  These  arrays 
generate  complex  logical  functions  by  wired  logic  connec¬ 
tions  of  single  pull  down  transistors.  This  wired  logic 
works  with  dynamic  CMOS  logic  and  pseudo-nMOS  logic.  Wired 
logic  does  not  work  with  static  CMOS  complementary  logic. 


PLAs  and  Weinberger  arrays  are  normally  constructed  using 
dynamic  CMOS  logic  or  pseudo-nMOS  logic. 

1.  Data  Path  Units 

The  data  path  units  used  in  the  current  nMOS  MSC 
controller  include  register,  organelle,  bit,  and  internal 
port  units2.  As  discussed  in  Paragraph  III. D. 10. a,  each 
process  in  the  design  specification  has  a  sequencer  in  the 
data  path.  The  data  path  sequencer  contains  all  of  the  ele¬ 
ments  of  the  MSC  FSM  shown  in  Figure  2.9  except  the 
combinational  logic.  The  combinational  logic  for  the  nMOS 
MSC  FSM  is  in  a  Weinberger  array, 
a.  Sequencer  Types 

There  are  three  types  of  sequencers :  counter¬ 
stack,  counter-no-stack,  and  no-counter-no-stack. 

(1)  No-Counter-No-Stack .  The  no-counter-no- 
stack  sequencer  is  the  simplest  sequencer.  This  type  of 
sequencer  is  used  for  processes  that  use  explicit  go  state¬ 
ments  for  all  state  transitions.  Figure  5.10  is  a  block 
diagram  of  a  no-counter-no-stack  sequencer  for  the  code 
fragment  in  Section  III.D.lO.a(l) .  It  is  constructed  from  a 

«  •  •  •  ,  ,  O 

register  unit,  an  internal  port  unit,  and  a  bit  unit  . 
There  is  a  control  line  from  the  combinational  logic  to  the 

2The  organization  and  function  of  units  is  discussed  in 
Paragraph  II. A. 1  and  the  functions  used  to  layout  the  units 
and  data  path  are  discussed  in  Paragraph  III. D. 13. 

3For  a  discussion  of  the  internal  structure  of  units, 
see  Section  II. A. 1. 


Figure  5.10  No-Counter-No-Stack  Sequencer 


sequencer  for  every  input  to  every  unit  to  select 
multiplexer  inputs  and  an  additional  control  line  to  the 
register  unit  to  enable  loading  the  register.  The  register 
unit  contains  a  register  that  stores  the  current  state  num¬ 
ber  and  a  multiplexer  that  selects  the  source  of  the  next 
state  number.  The  constant  (hardwired)  zero  input  to  the 
register  unit  is  selected  when  the  reset  signal  is  high. 
The  internal  port  unit  is  used  to  generate  the  go  state  num¬ 
bers  that  are  stored  in  state  number  memory.  The  go  state 
number  inputs  to  the  internal  port  unit  are  hardwired  con¬ 
stant  values.  Each  state  that  can  be  the  result  of  an  ex¬ 
plicit  go  state  transition  has  a  constant  input  to  the 
internal  port  unit.  Using  the  internal  port,  each  single 
bit  control  line  from  the  control  logic  array  selects  one 
integer  state  number  that  has  as  many  bits  as  the  data  path 
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word  size.  The  bit  unit  is  used  to  extract  groups  of  bits 
from  the  present  state  number  that  is  stored  in  the  register 
unit.  This  extraction  converts  word  sized  data  from  the 
data  path  into  bit  sized  data  for  the  combinational  logic. 
The  bits  are  used  in  the  combinational  logic  to  determine 
what  control  signals  to  apply  to  the  register  and  internal 
port  units.  Only  the  bits  that  are  required  to  uniquely 
represent  all  state  numbers  in  the  process  are  extracted. 
For  example,  if  the  data  path  word  size  is  eight  bits  and  a 
process  only  has  two  states,  the  least  significant  bit  (LSB) 
of  the  output  of  the  register  unit  will  be  extracted  by  the 
bit  unit.  This  one  bit  can  uniquely  identify  all  of  the 
valid  state  numbers.  The  seven  most  significant  bits  of  the 
register  and  internal  port  units  are  not  used  by  the 
controller. 

(2)  Counter-No-Stack .  The  counter-no-stack 
sequencer  is  used  for  processes  that  do  not  use  explicit  go 
statements  for  all  state  transitions.  Figure  5.11  is  a 
block  diagram  of  a  counter-no-stack  sequencer  for  the  code 
fragment  in  Section  III . D. 10 . a (2 ) .  The  counter-no-stack 
sequencer  contains  an  organelle  unit  and  all  of  the  units  in 
the  no-counter-no-stack  sequencer.  The  organelle  unit 
performs  the  increment  (1+)  function.  The  input  to  the 
organelle  unit  is  connected  to  the  register  unit  output  and 
the  output  of  the  organelle  unit  is  connected  to  one  of  the 
inputs  to  the  register  unit.  An  additional  internal  signal 


Figure  5.11  Counter-No-Stack  Sequencer 

named  sequencer-procname-go4  is  used  inside  the  combina¬ 
tional  logic  to  determine  whether  to  select  the  internal 
port  unit  or  the  organelle  unit  input  to  the  register  unit. 
The  input  selection  is  controlled  by  the  multiplexer  inside 
the  register  unit. 

(3)  Counter-Stack .  The  counter-stack  sequencer 
is  used  for  processes  that  contain  call  and  return 
statements.  Figure  5.12  is  a  block  diagram  of  a  counter¬ 
stack  sequencer  for  the  code  fragment  in  Section 

4Procname  in  this  signal  name  is  replaced  at  execution 
time  by  the  process  name  assigned  in  the  design  specifica¬ 
tion. 
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III.D. 10. a (3) .  The  counter-stack  sequencer  contains  addi¬ 


tional  register  units  and  all  of  the  units  in  the  counter- 


no-stack  sequencer.  The  additional  register  units  form  a 


last-in-first-out  (LIFO)  stack.  Since  the  code  fragment  in 


Section  III.D. 10. a (3)  specifies  a  stack  depth  of  one,  a  sin¬ 


gle  register  unit  is  added  for  the  LIFO  stack  in  Figure 


5.12.  The  output  of  the  organelle  unit  is  pushed  onto  the 


stack  and  the  stack  is  popped  to  generate  one  of  the  inputs 


to  the  register  unit  that  contains  the  state  number  memory. 


Internal  signals  named  sequencer-procname-call  and 
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Figure  5 . 12  Counter-Stack  Sequencer 
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sequencer-procname-return5  are  used  inside  the  combinational 
logic  to  select  an  input  to  the  state  number  memory  register 
unit  and  to  control  pushing  and  popping  the  LIFO  stack 
formed  by  the  additional  register  units, 
b.  Data  Path  Unit  Advantages. 

The  data  path  units  provide  a  useful  abstraction 
of  the  functions  that  are  required  to  manipulate  the  state 
number  of  an  MSC  FSM.  Data  path  units  use  existing  data 
path  software  to  generate  a  large  part  of  the  controller. 
All  units  can  be  located  in  a  single  data  path  using  the 
current  MSC  floor  plan  or  a  second  controller  data  path 
could  be  generated  using  the  existing  layout-data-path 
def symbol  in  the  data-path. 1  program6.  Generation  of  a  sep¬ 
arate  controller  data  path  requires  modification  of  the  .obj 
file  structure.  The  sequencer  units  would  be  removed  from 
the  data-path  section  of  the  .obj  file  and  placed  in  a  new 
control -data-path  section.  This  would  require  modification 
of  the  defstructs. 1,  prepass. 1,  and  extract. 1  programs.  The 
existing  layout-data-path  defsymbol  could  be  used  to  layout 
the  data-path  and  control-data-path  symbols.  A  separate 
controller  data  path  does  not  have  to  use  the  same  data  path 
word  size  as  the  arithmetic  and  logical  data  path.  Having  a 

5Procname  in  these  signal  names  is  replaced  at  execution 
time  by  the  process  name  assigned  in  the  design 
specification. 

6For  a  description  of  the  layout-data-path  defsymbol  in 
the  data-path. 1  program  see  Paragraph  III. D. 13. 


separate  controller  data  path  saves  space  if  the  number  of 
bits  required  to  represent  the  largest  state  number  is  less 
than  the  data  path  word  size.  With  a  single  data  path,  the 
maximum  number  of  states  in  a  process  is  limited  by  the 
largest  number  of  integers  that  can  be  represented  with  the 
data  path  word  size.  A  separate  controller  data  path  allows 
a  process  to  have  more  states  than  the  largest  number  of  in¬ 
tegers  that  can  be  represented  with  the  data  path  word  size, 
c.  Data  Path  Unit  Alternatives 

If  data  path  units  are  not  used,  each  of  these 
sequencer  functions  must  be  constructed  from  standard  cells 
or  added  to  the  combinational  logic.  Construction  of  these 
functions  from  standard  cells  requires  a  large  number  of  new 
and  modified  functions  in  the  MSC  programs.  Adding  these 
functions  to  the  combinational  logic  would  increase  the  com¬ 
plexity  of  the  functions  used  for  generation  of  the 
combinational  logic.  The  alternative  with  the  least  risk 
and  minimum  modification  of  existing  software  is  to  use  data 
path  organelles. 

2 •  Standard  Cell  or  Microprogram  ROM 

Either  standard  cells  or  a  microprogram  ROM  may  be 
used  to  implement  the  combinational  logic  of  the  MSC  FSM. 
a.  Standard  Cell 

Use  of  standard  cells  requires  that  all 
multiplexer  and  register  control  signals  be  expressed  as 
functions  of  the  values  of  signals,  ports,  registers,  and 


flags.  Generation  of  these  expressions  requires  significant 
processing  of  the  information  in  a  design  specification. 
Efficient  placement  and  routing  for  standard  cells  that  im¬ 
plement  the  control  signal  functions  is  a  very  difficult 
programming  problem.  The  size  of  the  combinational  logic,  a 
function  of  the  number  of  standard  cells  and  amount  of  in¬ 
terconnection,  is  not  a  linear  function  of  the  design 
specification  complexity.  Geometrical  or  exponential  growth 
in  size  is  expected  for  more  complex  design  specifications, 
b.  Microprogram  ROM 

A  microprogram  ROM  has  many  characteristics  that 
make  it  an  attractive  choice  for  the  combinational  logic  of 
the  MSC  FSM.  The  structure  is  simple  and  regular.  It  can 
be  constructed  entirely  of  modules  that  connect  by  abutting 
or  overlap.  This  significantly  reduces  routing  problems. 
The  required  contents  of  the  ROM  are  easily  derived  from  the 
design  specification.  There  is  a  one-to-one  correspondence 
of  the  states  and  sub-states  in  a  design  specification  to 
the  rows  in  the  ROM.  Design  specification  sub-states  are 
the  alternative  outputs  of  the  combinational  logic  section 
that  are  the  results  of  selecting  different  alternatives  for 
cond  statements  in  the  design  specification.  The  vertical 
dimension  of  the  ROM  is  a  linear  function  of  the  number  of 
states  and  sub-states  in  a  design  specification.  There  is  a 
row  in  the  ROM  for  each  state  and  sub-state.  The  horizontal 
dimension  of  the  ROM  is  a  linear  function  of  the  number  of 
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control  signals  required  by  the  data  path,  number  of  cond 
statements  in  the  design  specification,  and  the  number  of 
bits  required  to  represent  the  largest  state  number.  There 
is  a  column  in  the  ROM  for  each  control  signal  required  and 
each  cond  statement.  There  is  a  column  of  row  decoder  cells 
for  each  bit  required  to  represent  the  largest  state  number. 
The  number  of  logic  delays  in  the  row  decoders  is  a  function 
of  the  number  of  bits  required  to  represent  the  maximum 
state  number.  This  is  a  logarithmic  function  of  the  number 
of  states  in  a  process. 

C.  LOGIC  STRUCTURE  AND  ORGANIZATION  SELECTION 

The  selections  for  logic  structure  and  organization  of 
the  controller  are  static  CMOS  complementary  logic  for  the 
logic  structure  and  microprogram  ROM  for  the  controller 
organization.  The  speed,  size,  low  power,  and  simple  inter¬ 
connection  of  static  CMOS  complementary  logic  are  the  fea¬ 
tures  leading  to  its  selection.  The  simple  regular 
structure,  simplified  interconnection,  high  level  of  corre¬ 
spondence  to  the  design  specification,  and  orderly  growth  of 
the  microprogram  ROM  are  the  features  leading  to  its  selec¬ 
tion.  A  summary  of  the  evaluations  of  each  of  the  logic 
structure  and  organization  options  for  the  controller  is 
listed  on  the  next  page. 


Logic  Structures 

Static  CMOS  Complementary  Logic 

*  Can  satisfy  all  controller  requirements 

*  High  speed 

*  Medium  size 


*  Small  static  power  consumption 

*  Simple  interconnection 
Pseudo-nMOS  Logic 

*  Can  satisfy  all  controller  requirements 

*  Medium  speed 

*  Small  size 

*  Large  static  power  consumption 

*  Simple  interconnection 
Dynamic  CMOS  Logic 

*  Cannot  use  in  Mealy  FSM 
Clocked  CMOS  Logic 

*  Cannot  use  in  Mealy  FSM 
CMOS  Domino  Logic 

*  Cannot  use  in  Mealy  FSM 
Cascade  Voltage  Switch  Logic 

*  Static  form  can  satisfy  all  controller 

requirements 

*  Medium  speed 

*  Large  size 

*  Low  power 

*  Complex  interconnections 


Modified  Domino  Logic 

*  Cannot  use  in  Mealy  FSM 
Transmission  Gate  Logic 

*  Static  form  can  satisfy  all  controller 

requirements 

*  High  speed 

*  Small  size 

*  Low  power 

*  Complex  interconnections 
Organizations 

Data  Path  Units 

*  Useful  functional  abstraction 

*  Utilize  existing  software 
Standard  Cell  Combinational  Logic 

*  Complex  program  for  placement  and  routing 

*  Geometrical  or  exponential  growth 
Microprogram  ROM  Combinational  Logic 

*  Simple  regular  structure 

*  Simple  program  for  ROM  construction 

*  Linear  or  logarithmic  growth 
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VI.  CONTROLLER  DESIGN 


The  technology  independent  part  of  the  design  process 
for  the  MSC  microprogram  ROM  controller  involves  partition¬ 
ing  controller  functional  requirements  into  groups,  allocat¬ 
ing  groups  of  requirements  to  units,  establishing  floor 
plans  to  describe  the  physical  relationship  of  the  units, 
dividing  the  units  into  cells,  and  specifying  the  functions 
performed  by  each  cell.  No  internal  circuitry  is  specified 
in  the  technology  independent  design.  The  technology  depen¬ 
dent  part  of  the  design  process  involves  specifying  the  in¬ 
ternal  signal  conventions  and  circuitry  of  each  cell  in  the 
design. 

A.  FUNCTIONAL  REQUIREMENTS  PARTITIONS 

The  MSC  microprogram  ROM  controller  must  include  all 
functions  required  to  implement  MSC  finite  state  machines 
whose  structure  is  shown  in  Figure  2.9.  The  controller  must 
be  able  to  store  a  current  state  number.  This  storage  must 
be  clocked  so  that  the  current  state  number  changes  during 
state  transition  and  remains  constant  at  all  other  times. 
There  must  be  a  facility  for  selection  of  the  source  of  the 
next  state  number  to  be  loaded  into  storage.  There  must  be 
a  capability  to  generate  next  state  numbers  for  go  and  call 
statements  in  the  design  specification.  There  must  be  a 
FILO  stack  for  storage  of  return  state  numbers.  There  must 


be  an  incrementer  to  generate  a  next  sequential  state  num¬ 
ber.  There  must  be  a  combinational  logic  section  that 
generates  control  signals  for  the  data  path  and  the  other 
sections  of  the  controller.  The  outputs  of  this 
combinational  logic  section  must  be  functions  of  the  current 
state  number  and  signals  from  the  data  path.  All  require¬ 
ments  that  are  satisfied  by  the  control  logic  array  in  the 
nMOS  version  of  MSC  form  one  group  of  requirements  and  the 
requirements  satisfied  by  data  path  units  in  the  nMOS  ver¬ 
sion  of  MSC  form  the  second  group.  The  first  group  contains 
the  combinational  logic  requirements  and  the  second  group 
contains  all  remaining  requirements. 

B.  UNIT  IDENTIFICATION 

The  partitioned  controller  functional  requirements  are 
allocated  to  units  that  may  be  located  in  the  data  path  or 
microprogram  ROM. 

1 .  Data  Path  Units 

There  are  five  controller  units  located  in  the  data 
path:  the  process  state  number  register,  the  next  state 
number  internal  port,  the  bit,  the  FILO  stack  registers  and 
the  increment  organelle  units.  These  units  form  sequencers 
as  described  in  Sections  III. D. 10. a  and  V.B.l.  All  of  these 
units  are  located  in  the  single  data  path  of  the  current 
nMOS  MSC.  In  future  versions  of  MSC,  they  may  be  located  in 
the  same  data  path  or  in  a  separate  controller  data  path. 


2 .  Microprogram  ROM  Units 

The  microprogram  ROM  must  produce  outputs  that  are 
functions  of  test  signals  from  the  data  path  or  pads  and  the 
current  state  number  stored  in  the  process  state  number  reg¬ 
ister  data  path  unit.  Three  units  support  this  processing: 
the  ROM  array  unit,  the  row  decoder  unit,  and  the 
conditional  unit.  Additional  buffer  units  are  added  for  ef¬ 
ficiency.  The  configuration  of  these  units  is  shown  in  Fig¬ 
ure  6.1.  All  these  units  are  located  in  the  microprogram 
ROM  section  of  the  layout. 

a .  ROM  Array 

The  ROM  array  unit  contains  the  microprogram 
code  for  the  controller.  The  array  is  organized  in  horizon¬ 
tal  rows  of  words  and  vertical  columns  of  bits.  Each  row  of 
the  ROM  array  is  one  word  of  memory  that  is  associated  with 
one  state  or  substate  of  a  process  in  the  design  specifica¬ 
tion.  Each  column  of  the  ROM  array  generates  a  one  bit 
signal  that  is  used  internally  by  the  microprogram  ROM,  con¬ 
nected  to  data  or  control  lines  for  pads,  or  connected  to 
control  lines  for  the  data  path. 

b .  Row  Decoder 

The  row  decoder  unit  selects  a  row  in  the  ROM 
array  that  is  associated  with  a  state  in  a  process  defined 
in  the  design  specification.  One  row  is  selected  for  each 
process  based  on  the  current  state  number  stored  in  the  pro¬ 
cess  state  number  register  associated  with  the  process. 


State  Number  Bits 
from  Data  Path 


Test  Signals 
from  Data  Path 


Figure  6.1  Microprogram  ROM  Units 


There  is  a  row  decoder  unit  for  each  process  in  the  design 
specification. 

c.  Conditional 

The  conditional  unit  selects  a  row  in  the  ROM 
array  based  on  signals  from  the  data  path  or  pads.  There  is 
a  conditional  unit  for  each  cond  statement  in  the  design 
specification.  The  conditional  unit  has  an  input  for  each 
alternative  in  the  cond  statement  in  the  design  specifica¬ 
tion.  The  inputs  to  the  conditional  unit  are  connected  to 
test  lines  from  the  data  path  or  pads.  The  test  lines  may 


have  logical  one  or  zero  signals  based  on  conditions  in  the 
data  path.  No  more  than  one  row  in  the  ROM  array  will  be 
selected  by  each  conditional  unit.  Each  conditional  unit  is 
enabled  by  a  unique  one  bit  column  of  the  ROM  array.  If  the 
bit  column  for  the  conditional  unit  is  a  logic  zero,  the 
conditional  unit  will  not  select  any  row  in  the  ROM  array. 
If  the  bit  column  for  the  conditional  unit  is  a  logic  one, 
then  the  first  row  in  the  ROM  array  that  is  associated  with 
a  logic  one  input  to  the  conditional  unit  will  be  selected. 
If  the  last  alternative  in  the  cond  statement  in  the  design 
specification  is  a  default  true  (t)  and  all  of  the  inputs  to 
the  conditional  unit  are  logic  zero,  the  last  row  in  the  ROM 
array  associated  with  the  conditional  unit  will  be  selected, 
d.  Buffer 

Buffer  units  are  used  on  the  inputs  to  the  row 
decoder  units,  between  the  row  decoder  units  and  the  ROM  ar¬ 
ray,  and  between  the  conditional  units  and  the  ROM  array. 
The  buffers  convert  single  input  signals  into  complementary 
signals  and  may  provide  increased  drive  current. 

C.  FLOOR  PLAN 

Two  floor  plans  are  established  for  the  microprogram  ROM 
controller.  The  first  floor  plan  is  for  the  organization  of 
the  complete  controller  and  the  second  is  for  the  internal 
floor  plan  of  the  microprogram  ROM. 


.  Controller  Floor  Plan 

There  are  several  floor  plans  that  are  available  for 
the  microprogram  ROM  controller.  The  first  floor  plan, 
shown  in  Figure  6.2,  is  similar  to  the  current  nMOS  MSC 
floor  plan  with  the  control  logic  array  replaced  by  the  mi¬ 
croprogram  ROM.  The  data  path  units  for  the  sequencers  of 
the  controller  are  located  in  the  common  data  path.  The 
data  path  is  located  above  the  microprogram  ROM.  Alterna¬ 
tive  floor  plans,  shown  in  Figures  6.3  and  6.4,  use  a 
separate  control  data  path.  The  separate  control  data  path 
may  be  located  to  the  left  of  the  microprogram  ROM  or  below 
the  microprogram  ROM.  The  arithmetic  and  logical  data  path 
is  still  located  above  the  microprogram  ROM.  Any  one  of 
these  floor  plans  is  suitable  for  the  microprogram  ROM  con¬ 
troller.  The  separate  data  paths  can  be  generated  by 


Figure  6.2  Controller  Floor  Plan 
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Figure  6.4  Second  Alternate  Controller  Floor  Plan 

multiple  calls  of  the  layout-data-path  defstruct  in  the 
data-path.l  program. 
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The  internal  floor  plan  for  the  microprogram  ROM  is 


shown  in  Figure  6.5.  The  ROM  array  is  located  on  the  right 


of  the  microprogram  ROM  and  individual  bit  signals  may  be 


connected  to  the  top  or  bottom  of  each  bit  column.  The  rows 


for  the  first  processes  are  located  at  the  top  of  the  ROM 


array  followed  by  the  rows  of  the  second  process.  The  rows 


of  the  last  process  are  followed  by  the  rows  of  the  first 


conditional  group.  The  rows  of  the  first  conditional  group 


are  followed  by  the  rows  of  the  next  conditional  group.  The 


row  for  the  first  state  (state  number  =0)  is  at  the  top  of 


the  rows  for  a  process  and  the  row  for  the  last  state  is  at 


the  bottom  of  the  rows  for  a  process.  The  row  for  the  first 


alternative  of  a  conditional  group  is  at  the  top  of  the  rows 


for  the  conditional  group  and  the  row  for  the  last 
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Figure  6.5  Microprogram  ROM  Floor  Plan 


alternative  of  the  conditional  group  is  at  the  bottom  of  the 
rows  for  the  conditional  group.  Row  decoders  for  all  pro¬ 
cesses  are  located  at  the  top  left  of  the  microprogram  ROM. 
Conditional  units  are  located  at  tie  bottom  left  of  the 
microprogram  ROM.  Connections  for  the  test  signals  for  the 
conditional  units  are  made  on  the  left  of  the  microprogram 
ROM.  Buffer  units  are  located  between  the  row  decoders  and 
ROM  array,  between  the  conditionals  and  the  ROM  array,  and 
above  the  row  decoders.  Connections  to  the  buffer  units  for 
the  row  decoders  are  made  on  the  top  or  left  of  the  micro¬ 
program  ROM.  All  internal  connections  in  the  microprogram 
ROM  unit  are  made  by  cell  overlap  or  abutment.  There  is  no 
internal  routing  in  the  microprogram  ROM. 

D.  CELL  LOGIC  FUNCTIONS 

In  this  section,  the  microprogram  ROM  units  are  divided 
into  cells  and  the  logic  function  of  each  cell  is  deter¬ 
mined.  This  section  contains  technology  independent  func¬ 
tional  descriptions.  The  actual  circuits  contained  in  these 
cells  for  the  SCM05  technology  are  presented  in  Section 
VI .  E . 

I 

1.  ROM  Array  Cells 

The  ROM  array  is  constructed  from  three  basic  cells 
that  generate  a  logic  one,  a  logic  zero,  or  a  high  impedance 

|  on  the  vertical  bit  line.  The  cells  are  named  R0M1,  ROMO, 

i 

and  ROMnull.  The  configurations  of  the  cells  and  the  way 
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they  join  to  form  rows  are  shown  in  Figure  6.6.  In  all  of 
the  cell  figures,  cell  placement  is  controlled  by  the  left, 


right,  top,  and  bottom  (L  R  T  B)  alignment  points.  Nor¬ 
mally,  a  left  alignment  point  matches  a  right  alignment 
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Figure  6.6  ROM  Array  Cells 


point  in  an  adjacent  cell  and  a  top  alignment  point  matches 
a  bottom  alignment  point.  The  ROM  array  cells  are  the  ex¬ 
ception  to  this  convention.  Since  alternate  columns  of 
cells  in  the  ROM  array  are  mirrored  about  the  vertical  axis, 
right  alignment  points  are  aligned  with  right  alignment 
points  and  left  alignment  points  are  aligned  with  left 
alignment  points.  The  bottom  part  of  Figure  6.6  shows  four 
ROM  array  cells  that  have  been  joined  to  form  a  row.  Since 
the  alignment  points  are  inside  the  cells,  there  is  a  lot  of 
overlap.  The  arrows  outside  the  cell  indicate  possible  data 
or  power  flow  directions.  If  an  arrow  outside  the  cell 
matches  a  alignment  point  inside  the  cell,  then  the  align¬ 
ment  point  may  used  for  connections  outside  the  microprogram 
ROM.  All  connections  inside  the  microprogram  ROM  are  per¬ 
formed  by  cell  abutment  or  overlap, 
a.  R0M1  Cell 

The  R0M1  cell  generates  a  logic  one  on  the  ver¬ 
tical  bit  line  when  it  receives  row  selection;  when  it  is 
not  selected,  the  cell  produces  a  high  impedance  on  the  bit 
line.  The  cell  passes  the  bit  line,  power,  and  ground  ver¬ 
tically  and  passes  row  selection  horizontally.  The  cell  has 
left  and  right  alignment  points.  Alternate  columns  are  mir¬ 
rored  about  the  vertical  axis  to  permit  running  power  and 
ground  along  the  left  and  right  edges.  The  R0M1  cell  has 
signal  alignment  points  for  power,  ground,  and  the  bit  line 
on  the  top  and  bottom  of  the  cell. 


b.  ROMO  Cell 

The  ROMO  cell  generates  a  logic  zero  on  the  ver¬ 
tical  bit  line  when  it  receives  row  selection;  when  it  is 
not  selected,  the  cell  produces  a  high  impedance  on  the  bit 
line.  The  cell  passes  the  bit  line,  power,  and  ground  ver¬ 
tically  and  passes  row  selection  horizontally.  The  cell  has 
left  and  right  alignment  points.  Alternate  columns  are  mir¬ 
rored  about  the  vertical  axis  to  permit  running  power  and 
ground  along  the  left  and  right  edges.  The  ROMO  cell  has 
signal  alignment  points  for  power,  ground,  and  the  bit  line 
on  the  top  and  bottom  of  the  cell. 

c.  ROMnull  Cell 

The  ROMnull  cell  has  no  connection  between  the 
signal  on  the  vertical  bit  line  and  row  selection.  The  cell 
passes  the  bit  line,  power,  and  ground  vertically  and  passes 
row  selection  horizontally.  The  cell  has  left  and  right 
alignment  points.  Alternate  columns  are  mirrored  about  the 
vertical  axis  to  permit  running  power  and  ground  along  the 
left  and  right  edges.  The  ROMnull  cell  has  signal  alignment 
points  for  power,  ground,  and  the  bit  line  on  the  top  and 
bottom  of  the  cell. 


Evenlnverter , 


EvenConnect,  OddConnect,  and  Two-State.  The  configuration 
of  the  cells  that  form  a  row  decoder  for  a  sixteen  state 
process  is  in  Figure  6.7.  A  cell  is  not  required  below  the 
bottom  DecodeEvenl  cell  in  the  Bit  2  column.  This  De- 
codeEvenl  cell  drives  both  the  DecodeOddO  and  DecodeOddl 
cells  at  the  bottom  of  the  Bit  1  column. 

a.  DecodeLSB  Cell 

The  DecodeLSB  cell  decodes  the  least  significant 
bit  (LSB)  of  the  binary  state  number.  This  cell  is  shown  in 
Figure  6.8.  This  cell  controls  two  rows  of  the  ROM  array. 
This  arrangement  allows  the  size  of  the  DecodeLSB  cell  to 
match  the  small  vertical  dimension  of  the  ROM  array  cells. 
If  the  DecodeLSB  receives  an  enable  signal  from  the  cell  on 
its  left,  it  selects  one  of  the  two  ROM  array  rows.  If  the 
LSB  is  zero,  the  top  row  is  selected.  If  the  LSB  is  one, 
the  bottom  row  is  selected.  The  cell  passes  the  LSB,  the 
complement  of  the  LSB,  power,  and  ground  vertically.  The 
cell  receives  an  enable  signal  on  the  left  and  generates  two 
row  selections  on  the  right.  The  cell  has  left  and  right 
alignment  points.  The  right  alignment  point  coincides  with 
the  left  alignment  point  of  the  top  RowBuffer  on  its  right. 

b.  DecodeEvenO  and  DecodeEvenl  Cells 

The  DecodeEvenO  and  DecodeEvenl  cells  decode 
even  bits  of  the  binary  state  number.  These  cells  are  shown 
in  Figure  6.9.  If  the  DecodeEvenO  cell  receives  an  enable 
signal  from  the  cell  on  its  left  and  the  even  bit  of  the 
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Figure  6.7  Row  Decoder 


binary  state  number  associated  with  it  is  zero,  it  enables 
the  cell  on  its  right.  If  the  DecodeEvenl  cell  receives  an 
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Figure  6.8  DecodeLSB  Cell 


enable  signal  from  the  DecodeEvenO  cell  above  it  and  the 
even  bit  of  the  binary  state  number  associated  with  it  is 
one,  it  enables  the  cell  on  its  right.  Both  cells  pass  the 
even  bit  of  the  binary  state  number,  the  complement  of  the 
even  bit  of  the  binary  state  number,  power,  and  ground  ver¬ 
tically.  The  DecodeEvenO  cell  receives  an  enable  signal  on 
the  left  and  generates  an  enable  on  the  right.  The  De¬ 
codeEvenO  also  transmits  the  enable  signal  it  receives  on 
the  left  to  the  DecodeEvenl  cell  below  it.  The  DecodeEvenl 
cell  receives  an  enable  signal  from  the  DecodeEvenO  cell 
above  it  and  generates  an  enable  on  the  right.  If  the  cells 
are  in  the  left  column  of  the  row  decoder,  the  enable  for 
the  two  cells  may  be  received  from  above  the  DecodeEvenO 
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Figure  6.9  DecodeEvenO  and  DecodeEvenl  Cells 


cell  or  below  the  DecodeEvenl  cell.  The  cells  have  left 
right,  and  top  alignment  points. 


c.  DecodeOddO  and  DecodeOddl  Cells 

The  DecodeOddO  and  DecodeOddl  cells  decode  odd 
bits  of  the  binary  state  number.  These  cells  are  shown  in 
Figure  6.10.  If  the  DecodeOddO  cell  receives  an  enable  sig¬ 
nal  from  the  cell  on  its  left  and  the  odd  bit  of  the  binary 
state  number  associated  with  it  is  zero,  it  enables  the  cell 
on  its  right.  If  the  DecodeOddl  cell  receives  an  enable 
signal  from  the  DecodeOddO  cell  above  it  and  the  odd  bit  of 
the  binary  state  number  associated  with  it  is  one,  it  en¬ 
ables  the  cell  on  its  right.  Both  cells  pass  the  odd  bit  of 
the  binary  state  number,  the  complement  of  the  odd  bit  of 
the  binary  state  number,  power,  and  ground  vertically.  The 
DecodeOddO  cell  receives  an  enable  signal  on  the  left  and 
generates  an  enable  on  the  right.  The  DecodeOddO  also 
transmits  the  enable  signal  it  receives  on  the  left  to  the 
DecodeOddl  cell  below  it.  The  DecodeOddl  cell  receives  an 
enable  signal  from  the  DecodeOddO  cell  above  it  and  gener¬ 
ates  an  enable  on  the  right.  If  the  cells  are  for  the  bit 
that  is  one  less  than  the  most  significant  bit  (MSB) ,  the 
enable  for  the  two  cells  may  be  received  from  the  cell  above 
the  DecodeOddO  cell  or  below  the  DecodeOddl  cell.  The  cells 
have  left,  right,  and  top  alignment  points. 

d.  Evenlnverter  and  Oddlnverter  Cells 

The  Evenlnverter  and  Oddlnverter  cells  are  used 
to  connect  the  most  significant  bit  (MSB)  to  the  row  de- 
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Figure  6.10  DecodeOddO  and  DecodeOddl  Cells 

Evenlnverter  has  one  set  of  DecodeEvenO  and  DecodeEvenl 
cells  above  it  and  one  set  below  it.  The  Oddlnverter  has 
one  set  of  DecodeOddO  and  DecodeOddl  cells  above  it  and  one 


Enable  _ 

Vdd  OOut  Bit  Bit  GND 


Vdd  Enable  ^  Bit  GND 

1  Out 


Figure  6.11  Evenlnverter  and  Oddlnverter  Cells 


set  below  it.  If  the  number  of  states  is  not  an  even  power 
of  two  and  less  than  1.5  times  the  largest  power  of  two  in 


the  number  of  states,  the  lower  set  of  DecodeEven  or 


DecodeOdd  cells  may  be  replaced  by  an  inverter.  The  Evenln- 
verter  receives  an  odd  MSB  on  the  left  and  the  Oddlnverter 
receives  an  even  MSB  on  the  left.  If  the  MSB  is  zero,  the 
Evenlnverter  or  Oddlnverter  enables  the  cells  above  it.  If 
the  MSB  is  one,  the  Evenlnverter  or  Oddlnverter  enables  the 
cells  below  it.  The  Evenlnverter  cell  pass  the  even  bit  of 
the  binary  state  number,  the  complement  of  the  even  bit  of 
the  binary  state  number,  power,  and  ground  vertically.  The 
Oddlnverter  cell  pass  the  odd  bit  of  the  binary  state  num¬ 
ber,  the  complement  of  the  odd  bit  of  the  binary  state  num¬ 
ber,  power,  and  ground  vertically.  Both  cells  have  an 
alignment  point  on  the  right  and  a  signal  alignment  point 
for  the  MSB  on  the  left. 

e.  EvenConnect  and  Odd Connect  Cells 

The  EvenConnect  cell  is  used  to  connect  DecodeEvenO, 
DecodeEvenl,  and  Evenlnverter  cells  that  do  not  abut  verti¬ 
cally.  The  OddConnect  cell  is  used  to  connect  DecodeOddO, 
DecodeOddl,  and  Oddlnverter  cells  that  do  not  abut  verti¬ 
cally.  These  cells  are  shown  in  Figure  6.12.  Both  cells 
pass  a  bit  of  the  binary  state  number,  the  complement  of  a 
bit  of  the  binary  state  number,  cell  enable,  power,  and 
ground  vertically.  Both  cells  have  alignment  points  on  the 
left  and  right. 

f.  Two-State  Cell 

The  Two-State  cell  is  used  for  row  decoding  for 
processes  that  have  only  two  states.  This  cell  is  shown  in 
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Figure  6.13  Two-State  Cell 


match  the  small  vertical  dimension  of  the  ROM  array  cells. 
The  cell  receives  a  single  bit  of  the  binary  state  number  on 
the  left.  If  the  single  bit  of  the  binary  state  number  is 
zero,  it  selects  the  top  row  of  the  two  ROM  array  rows.  If 
the  single  bit  of  the  binary  state  number  is  one,  it  selects 
the  bottom  row  of  the  two  ROM  array  rows.  The  cell  passes 
power  and  ground  vertically.  The  cell  has  an  alignment 
point  on  the  right  and  a  signal  alignment  for  the  single  bit 
of  the  binary  state  number  on  the  left.  The  right  alignment 
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point  coincides  with  the  left  alignment  point  of  the  top 
RowBuffer  on  its  right. 


3 .  Conditional  Cells 

Conditional  cells  are  arranged  in  groups  with  one 

group  for  each  cond  statement  in  the  design  specification. 

The  configuration  of  the  conditional  cells  for  the  following 

segment  of  a  design  specification  is  shown  in  Figure  6.14: 

(cond  (testl  (setq  a  b) ) 

(t  (setq  a  c) ) ) 

(cond  (test2  (setq  b  c) ) 

(test3  (setq  b  a)) 

(t  (setq  b  a) ) ) 


If  the  conditional  group  is  enabled,  it  may  select  one  of 
the  rows  in  the  ROM  array.  The  row  selected  is  determined 
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Figure  6.14  Conditional  Cells 


by  the  test  signals  connected  to  the  conditional  cells  and 
the  configuration  of  the  conditional  cells.  The  condi¬ 
tional  cells  are  COND,  CONDtrue,  CONDfeed,  topCONDfeed, 
CONDtap,  CONDpass,  and  CONDnopass. 

a.  COND  Cell 

The  COND  cell  is  used  to  select  a  row  of  the  ROM 
array  based  on  enable  and  test  inputs.  This  cell  is  shown 
in  Figure  6.15.  The  COND  cell  receives  an  enable  from  the 
cell  above  it  and  a  test  signal  on  the  left.  If  the  COND 
cell  is  enabled  and  the  test  signal  is  true,  the  COND  cell 
selects  the  cell  on  the  right.  If  the  COND  cell  is  enabled 
and  the  test  signal  is  false,  the  COND  cell  enables  the 
cell  below  it.  The  cell  passes  power  and  ground  vertically. 
The  cell  has  an  alignment  point  on  the  right  and  a  signal 
alignment  for  the  test  signal  on  the  left. 

b.  CONDtrue  Cell 

The  CONDtrue  cell  is  used  to  select  a  row  of  the 
ROM  array  based  on  an  enable  input.  This  cell  is  shown  in 
Figure  6.15.  The  CONDtrue  cell  receives  an  enable  from  the 
cell  above  it.  If  the  CONDtrue  cell  is  enabled,  the 
CONDtrue  cell  selects  the  cell  on  the  right.  The  cell 
passes  power  and  ground  vertically.  The  cell  has  an  align¬ 
ment  point  on  the  right. 
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Figure  6.15  COND  and  CONDtrue  Cells 


c.  CONDfeed  and  TopCONDfeed  Cells 

The  CONDfeed  and  topCONDfeed  cells  form  the  top 
of  conditional  cell  groups.  These  cells  are  shown  in  Figure 
6.16.  They  transmit  an  enable  from  the  CONDtap  or  CONDpass 
cell  on  the  right  to  the  COND  cell  below  the  topCONDfeed  or 
CONDfeed  cell.  The  CONDfeed  cell  is  used  if  there  is  an¬ 
other  conditional  group  above  it  and  the  topCONDfeed  cell  is 
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Figure  6.16  TopCONDfeed  and  CONDfeed  Cells 


used  if  there  is  a  row  decoder  above  it.  The  cells  pass 


power  and  ground  vertically.  Both  cells  have  alignment 


points  on  the  top,  right,  and  bottom.  The  top  and  bottom 


alignment  points  determine  the  spacing  of  the  entire  hori¬ 


zontal  row  of  the  microprogram  ROM. 


d.  CONDtap  Cell 


The  CONDtap  cell  extracts  a  bit  from  the  ROM  ar¬ 


ray  and  transmits  it  to  the  cell  on  the  left.  The  value  of 


the  bit  is  controlled  by  ROMO  and  ROM1  cells  located  in  the 
column  above  or  below  the  CONDtap  cell.  This  cell  is  shown 
in  Figure  6.17.  The  cell  passes  power,  ground,  and  a  bit 
line  vertically.  The  cell  has  right  and  left  alignment 
points. 

e.  CONDpass  Cell 

The  CONDpass  cell  transmits  a  bit  from  the  cell 
on  the  right  to  a  cell  on  the  left.  This  cell  is  shown  in 
Figure  6.17.  The  cell  passes  power,  ground,  and  a  bit  line 
vertically.  The  cell  has  right  and  left  alignment  points. 

f.  CONDnopass  Cells 

The  CONDnopass  cell  passes  power,  ground,  and  a 
bit  line  vertically.  This  cell  is  shown  in  Figure  6.17. 
The  cell  has  right  and  left  alignment  points. 

4 .  Buffer  Cells 

The  buffer  cells  generate  complementary  outputs  for 
single  inputs.  The  configurations  of  units  using  the  buffer 
cells  are  shown  in  Figures  6.7,  6.13,  and  6.14.  The  drive 
current  on  the  output  of  the  buffers  may  be  much  greater 
than  the  input  current  of  the  buffer.  The  buffer  cells  are 
RowBuffer,  CONDbuffer,  LSBbuffer,  EvenBuffer,  and  OddBuffer. 

a.  RowBuffer  Cell 

The  RowBuffer  cell  forms  the  buffer  between  the 
row  decoders  and  the  ROM  array.  The  cell  is  shown  in  Figure 
6.18.  The  cell  receives  a  select  on  the  left  and  provides 
complementary  select  outputs  with  greater  drive  current  on 


Vdd  Vdd 

or  or 

QND  Bit  GND 


Enable 


Vdd  Vdd 

or  or 

GND  Bit  GND 


CONDnopass 


Vdd  Bit  Vdd 
or  or 

GND  GND 


Vdd  Bit  Vdd 
or  or 

GND  GND 


Vdd  Vdd 

or  or 

GND  Bit  GND 


Enable 


Enable 


Vdd  Bit  Vdd 
or  or 

GND  GND 


Figure  6.17  CONDtap,  CONDpass,  and  CONDnopass  Cells 


the  right.  The  cell  passes  power  and  ground  vertically. 
The  cell  has  left,  right,  top,  and  bottom  alignment  points. 
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Figure  6.18  RowBuffer  and  CONDbuffer  Cells 

The  top  and  bottom  alignment  points  determine  the  spacing 
of  the  entire  horizontal  row  of  the  microprogram  ROM. 
b.  CONDbuffer  Cell 

The  CONDbuffer  cell  forms  the  buffer  between  the 
conditional  cells  and  the  ROM  array.  The  cell  is  shown  in 


Figure  6.18.  The  cell  receives  the  complement  of  a  select 
on  the  left  and  provides  complementary  select  outputs  with 


greater  drive  current  on  the  right.  The  cell  passes  power 
and  ground  vertically.  The  cell  has  left,  right,  top,  and 
bottom  alignment  points.  The  top  and  bottom  alignment 
points  determine  the  spacing  of  the  entire  horizontal  row  of 
the  microprogram  ROM. 

c.  LSBbuffer  Cell 

The  LSBbuffer  cell  provides  complementary  bit 
signals  for  the  DecodeLSB  cells.  This  cell  is  shown  in 
Figure  6.19.  The  cell  receives  a  least  significant  bit 
(LSB)  input  on  the  right  and  produces  complementary  bit 
outputs  on  the  bottom.  The  cell  passes  power  and  ground 
vertically.  The  cell  has  an  alignment  point  on  the  bottom 
and  a  signal  alignment  point  on  the  right  for  the  LSB. 
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Figure  6.19  LSBbuffer  Cell 


d.  EvenBuffer  Cell 


The  EvenBuffer  cell  provides  complementary  bit 
signals  for  the  DecodeEvenO  and  DecodeEvenl  cells.  This 
cell  is  shown  in  Figure  6.20.  The  cell  receives  an  even  bit 
of  the  binary  state  number  as  input  on  the  top  and  produces 
complementary  bit  outputs  on  the  bottom.  The  cell  passes 
power  and  ground  vertically.  The  cell  has  an  alignment 
point  on  the  bottom  and  a  signal  alignment  point  on  the  top 
for  the  even  bit. 
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Figure  6.20  EvenBuffer  and  OddBuffer  Cells 
e.  OddBuffer  Cell 

The  OddBuffer  cell  provides  complementary  bit 
signals  for  the  DecodeOddO  and  DecodeOddl  cells.  This  cell 
is  shown  in  Figure  6.20.  The  cell  receives  an  odd  bit  of 
the  binary  state  number  as  input  on  the  top  and  produces 
complementary  bit  outputs  on  the  bottom.  The  cell  passes 
power  and  ground  vertically.  The  cell  has  an  alignment 


point  on  the  bottom  and  a  signal  alignment  point  on  the  top 
for  the  odd  bit. 

E.  CELL  INTERNAL  STRUCTURE 

In  this  section,  the  internal  structure  of  each  cell  in 
the  microprogram  ROM  is  determined. 

1.  ROM  Array  Cells 

The  ROM  array  is  constructed  from  three  basic  cells 
that  generate  a  logic  one,  a  logic  zero,  or  a  high  impedance 
on  the  vertical  bit  line.  The  cells  are  named  ROMl,  ROMO, 
and  ROMnull. 

a.  ROMl  Cell 

The  ROMl  cell  has  power,  ground,  and  bit  line 
routed  vertically  in  metall.  The  power  and  ground  in  metall 
inside  the  ROM  array  connect  to  metal 2  power  and  ground 
buses  outside  the  ROM  array  using  metal2  contacts.  Thus, 
the  bit  lines  are  able  to  pass  under  the  buses.  The  select 
signal  and  the  complement  of  the  select  signal  are  routed 
horizontally  in  metal2.  The  ROMl  cell  contains  a  p-type 
transistor  connected  between  power  and  the  signal  line  with 
the  gate  connected  to  the  complement  of  the  select  signal  as 
shown  in  Figure  6.21. 

b.  ROMO  Cell 


The  ROMO  cell  has  power,  ground,  and  bit  line 
routed  vertically  in  metall.  The  select  signal  and  the  com¬ 
plement  of  the  select  signal  are  routed  horizontally  in 
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metal2.  The  ROMO  cell  contains  a  n-type  transistor  con¬ 
nected  between  ground  and  the  signal  line  with  the  gate  con¬ 
nected  to  the  select  signal  as  shown  in  Figure  6.21. 

c.  ROMnull  Cell 

The  ROMnull  cell  has  power,  ground,  and  bit  line 
routed  vertically  in  metall.  The  select  signal  and  the  com¬ 
plement  of  the  select  signal  are  routed  horizontally  in 
metal2.  The  ROMnull  cell  is  shown  in  Figure  6.21. 

2.  Row  Decoder  Cells 

The  row  decoder  cells  select  a  single  row  of  the 
microprogram  ROM  based  on  a  binary  state  number.  The  row 
decoder  cells  are  DecodeLSB,  DecodeEvenO,  DecodeEvenl, 
DecodeOddO,  DecodeOddl,  Evenlnverter,  Oddlnverter, 
EvenConnect,  OddConnect,  and  Two-State.  To  simplify  the 
circuitry,  the  decoders  for  even  bits  use  NOR  gates  and  the 
decoders  for  odd  bits  use  NAND  gates.  The  outputs  of  the 
NOR  gates  are  active  high  and  the  inputs  to  the  NOR  gates 
are  active  low.  The  outputs  of  the  NAND  gates  are  active 
low  and  the  inputs  to  the  NAND  gates  are  active  high.  The 
logic  configuration  of  the  decoders  for  the  top  two  rows  of 
the  row  decoder  shown  in  Figure  6.7  is  illustrated  in  Figure 
6.22.  The  input  for  the  most  significant  bit  comes  from  an 
Evenlnverter  cell. 

a.  DecodeLSB,  DecodeEvenO,  and  DecodeEvenl  Cells 


The  DecodeLSB  cell  contains  two  NOR  gates  and 
the  DecodeEvenO  and  DecodeEvenl  cells  contain  single  NOR 
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gates.  The  logic  configurations  of  these  cells  is  shown  in 
Figure  6.23.  An  SCMOS  NOR  gate  is  shown  in  Figure  6.24. 
The  enable  signals  for  these  cells  are  active  low  so  an  en¬ 
able  is  a  logic  zero.  The  signal (s)  output  by  the  gates  are 
active  high  so  a  high  is  a  logic  one.  In  the  DecodeLSB 
cell,  one  of  the  inputs  of  each  NOR  gate  is  connected  to  the 
line  for  the  inverse  enable  signal.  The  other  input  of  the 
top  gate  is  connected  to  the  LSB  line  and  the  other  input  of 
the  bottom  gate  is  connected  to  the  line  for  the  complement 
of  the  LSB.  One  of  the  inputs  of  the  NOR  gate  in  the 
DecodeEvenO  and  DecodeEvenl  cells  is  connected  to  the  enable 
input.  The  other  input  of  the  NOR  gate  in  the  DecodeEvenO 
cell  is  connected  to  the  bit  line.  The  other  input  of  the 
NOR  gate  in  the  DecodeEvenl  cell  is  connected  to  the  line 
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Figure  6.23  DecodeLSB,  DecodeEvenO,  and  DecodeEvenl  Logic 


for  the  complement  of  the  even  bit.  Power,  ground,  the  bit 
line,  and  the  line  for  the  complement  of  the  bit  are  routed 
vertically  in  metal l.  The  enable  and  select  signals  are 
routed  in  Metal2. 

b.  DecodeOddO  and  DecodeOddl  Cells 

The  DecodeEvenO  and  DecodeEvenl  cells  contain 
single  NAND  gates.  The  logic  configurations  of  these  cells 
are  shown  in  Figure  6.25.  An  SCMOS  NAND  gate  is  shown  in 
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Figure  6.24  NOR  Gate 
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Figure  6.25  DecodeOddO  and  DecodeOddl  Logic 

Figure  6.26.  The  enable  signal  for  these  cells  is  active 
high  so  an  enable  is  a  logic  one.  The  enable  signal  output 
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Figure  6.26  NAND  Gate 

by  the  cells  is  active  low  so  an  enable  is  a  logic  zero. 
One  of  the  inputs  of  the  NAND  gate  in  the  DecodeOddO  and  De- 
codeOddl  cells  is  connected  to  the  enable  input.  The  other 
input  of  the  NAND  gate  in  the  DecodeOddO  cell  is  connected 
to  the  line  for  the  complement  of  the  odd  bit  line.  The 
other  input  of  the  NAND  gate  in  the  DecodeOddl  cell  is  con¬ 
nected  to  the  odd  bit  line.  Power,  ground,  the  bit  line, 
and  the  line  for  the  complement  of  the  bit  are  routed  verti¬ 
cally  in  metall.  The  enable  and  select  signals  are  routed 
in  Meta 12 . 
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c.  Evenlnverter  and  Oddlnverter  Cells 

The  Evenlnverter  and  Oddlnverter  cells  contain 
single  inverters.  The  logic  configurations  of  these  cells 
are  shown  in  Figure  6.27.  An  SCMOS  inverter  gate  is  shown 
in  Figure  6.28.  The  most  significant  bit  (MSB)  is  routed  to 
the  input  of  the  inverter.  The  MSB  is  also  routed  to  the 
enable  input  of  the  top  pair  of  DecodeEvenO  and  DecodeEvenl 
cells  for  the  Evenlnverter.  The  MSB  is  also  routed  to  the 
enable  input  of  the  bottom  pair  of  DecodeOddO  and  DecodeOddl 
cells  for  the  Oddlnverter.  The  output  of  the  inverter  is 
routed  to  the  enable  input  of  the  bottom  pair  of  DecodeEvenO 
and  DecodeEvenl  cells  for  the  Evenlnverter.  The  output  of 
the  inverter  is  routed  to  the  enable  input  of  the  top  pair 
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Figure  6.27  Evenlnverter  and  Oddlnverter  Logic 


Figure  6.28  Inverter 

of  DecodeOddO  and  DecodeOddl  cells  for  the  Oddlnverter. 
Power,  ground,  the  bit  line,  and  the  line  for  the  complement 
of  the  bit  are  routed  vertically  in  metall.  The  MSB  and  en¬ 
able  signals  are  routed  in  Metal2. 

d.  EvenConnect  and  OddConnect  Cells 

The  EvenConnect  and  OddConnect  cells  contain 
metal  routing.  Power,  ground,  the  bit  line,  and  the  line 
for  the  complement  of  the  bit  are  routed  vertically  in 
metall.  The  enable  signals  are  routed  vertically  in  Metal2. 

e.  Two-State  Cell 

The  Two-State  cell  contains  a  single  inverter. 
The  logic  configuration  of  the  cell  is  shown  in  Figure  6.29. 
An  SCMOS  inverter  gate  is  shown  in  Figure  6.28.  The  single 
bit  of  the  binary  state  number  is  routed  to  the  input  of  the 
inverter.  The  single  bit  of  the  binary  state  number  is  also 
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Figure  6.29  Two-State  Logic 


routed  to  the  select  input  of  the  bottom  RowBuffer  connected 
to  the  Two-State  cell.  The  output  of  the  inverter  is  routed 
to  the  select  input  of  the  top  RowBuffer  connected  to  the 
Two-State  cell.  Power  and  ground  are  routed  vertically  in 
metall.  The  single  bit  of  the  binary  state  number  and  se¬ 
lect  signals  are  routed  in  Metal2. 


Conditional  cells  are  arranged  in  groups  with  one 
group  for  each  cond  statement  in  the  design  specification. 
If  the  conditional  group  is  enabled,  it  may  select  one  of 
the  rows  in  the  ROM  array.  The  row  selected  is  determined 
by  the  test  signals  connected  to  the  conditional  cells  and 
the  configuration  of  the  conditional  cells.  The  conditional 
cells  are  COND,  CONDtrue,  CONDfeed,  topCONDfeed,  CONDtap, 
CONDpass,  and  CONDnopass. 
a.  COND  Cell 

The  COND  cell  contains  an  inverter,  a  NAND  gate, 
and  a  NOR  gate.  These  gates  are  shown  in  Figures  6.24, 


6.26,  and  6.28.  The  logical  configuration  of  the  COND  cell 
is  shown  in  Figure  6.30.  The  enable  input,  test  input,  and 
enable  output  are  active  high  so  a  high  is  a  logical  one. 
The  select  output  is  active  low  so  a  low  is  a  logical  one. 
The  enable  input  is  connected  to  the  input  of  the  inverter 
and  one  input  of  the  NAND  gate.  The  test  input  is  connected 
to  one  input  of  the  NOR  gate  and  one  input  of  the  NAND  gate. 
The  output  of  the  inverter  is  connected  to  one  input  of  the 
NOR  gate.  The  output  of  the  NAND  gate  is  connected  to  the 
select  input  of  the  CONDbuffer  and  the  output  of  the  NOR 
gate  is  connected  to  the  enable  output.  Power,  ground,  and 
the  enable  signals  are  routed  vertically  in  metal 1  or 
polysilicon.  The  test  input  and  select  signals  are  routed 
in  Metal2 . 
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Figure  6.30  COND  Logic 


6.31.  An  SCMOS  inverter  gate  is  shown  in  Figure  6.9.  The 


enable  input  is  routed  to  the  input  of  the  inverter.  The 


output  of  the  inverter  is  routed  to  the  select  input  of  a 


CONDbuffer.  Power,  ground,  and  the  enable  signal  are  routed 


vertically  in  metall  or  polysilicon.  The  select  signal  is 


routed  in  Metal2. 
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Figure  6.31  CONDtrue  Logic 


c.  CONDfeed,  TopCONDfeed,  CONDtap,  CONDpass,  and 
CONDnopass  Cells 


The  CONDfeed,  TopCONDfeed,  CONDtap,  CONDpass, 


and  CONDnopass  cells  route  power,  ground,  and  bit  lines  ver¬ 


tically  in  metall  and  enable  lines  horizontally  in  metal2. 


The  buffer  cells  generate  complementary  outputs  for 


single  inputs.  The  drive  current  on  the  output  of  the 


buffers  may  be  much  greater  than  the  input  current  of  the 


buffer.  The  buffer  cells  are  RowBuffer,  CONDbuffer, 
LSBbuffer,  EvenBuffer,  and  OddBuffer. 

a.  RowBuffer  Cell 

The  RowBuffer  cell  contains  two  inverters  that 
are  configured  as  superbuffers.  The  logic  configuration  of 
this  cell  is  shown  in  Figure  6.32.  An  SCMOS  inverter  gate 
is  shown  in  Figure  6.28.  The  select  input  is  connected  to 
the  input  of  the  first  inverter.  The  output  of  the  first 
inverter  is  connected  to  the  input  of  the  second  inverter 
and  to  the  line  for  the  complement  of  the  row  select  signal. 
The  output  of  the  second  inverter  is  connected  to  the  line 
for  the  row  select  signal.  Power  and  ground  are  routed  ver¬ 
tically  in  metall.  The  select  signals  are  routed  in  Metal2. 

b.  CONDbuffer  Cell 

The  CONDbuffer  cell  contains  two  inverters  that 
are  configured  as  superbuffers.  The  logic  configuration  of 
this  cell  is  shown  in  Figure  6.32.  An  SCMOS  inverter  gate 
is  shown  in  Figure  6.28.  The  select  input  is  connected  to 
the  input  of  the  first  inverter.  The  output  of  the  first 
inverter  is  connected  to  the  input  of  the  second  inverter 
and  to  the  line  for  the  row  select  signal.  The  output  of 
the  second  inverter  is  connected  to  the  line  for  the 
complement  of  the  row  select  signal.  Power  and  ground  are 
routed  vertically  in  metall.  The  select  signals  are  routed 
in  Metal2. 


CONDBuffer 

Figure  6.32  RowBuffer  and  CONDbuffer  Logic 
c.  LSBbuffer  Cell 

The  LSBbuffer  cell  contains  two  inverters  that 
are  configured  as  superbuffers.  The  logic  configuration  of 
this  cell  is  shown  in  Figure  6.33.  An  SCMOS  inverter  gate 
is  shown  in  Figure  6.28.  The  LSB  input  is  connected  to  the 
input  of  the  first  inverter.  The  output  of  the  first 
inverter  is  connected  to  the  input  of  the  second  inverter 
and  to  the  line  for  the  complement  of  the  LSB  signal.  The 
output  of  the  second  inverter  is  connected  to  the  line  for 


Figure  6.33  LSBbuffer  Logic 


the  LSB  signal.  Power,  ground,  and  the  output  signals  are 
routed  vertically  in  metall.  The  LSB  input  signal  is  routed 
in  Metal 2. 

d.  EvenBuffer  and  OddBuffer  Cells 

The  EvenBuffer  and  OddBuffer  cells  contain  sin¬ 
gle  inverters.  The  logic  configuration  of  these  cells  is 
shown  in  Figure  6.34.  An  SCMOS  inverter  gate  is  shown  in 
Figure  6.28.  The  bit  input  is  routed  to  the  input  of  the 
inverter  and  to  the  bit  line  output.  The  output  of  the  in¬ 
verter  is  routed  to  the  line  for  the  complement  of  the  bit. 


Figure  6.34  EvenBuffer  and  OddBuffer  Logic 


Power,  ground,  and  the  bit  input  signal  are  routed  in 
metall.  The  output  signals  are  routed  in  Metal2. 

F.  DESIGN  VERIFICATION 

The  microprogram  controller  design  satisfies  the  controller 
requirements  and  conforms  to  the  controller  goals.  The  con¬ 
trol  signals  generated  by  the  controller  are  functions  of 
the  test  signals  from  the  data  path  and  the  current  state 
numbers  of  the  sequencers  for  the  processes  in  the  design 
specification.  This  makes  the  controller  a  Mealy  FSM.  The 
controller  contains  units  that  perform  all  of  the  functions 
shown  in  Figure  2.9  for  the  MSC  FSM.  The  growth  of  the  size 
of  the  controller  is  based  on  linear  functions  of  parameters 
of  the  design  specification.  The  controller  has  a  regular 
structure.  All  cells  in  the  microprogram  ROM  connect  by 
abutment  or  overlap.  The  circuitry  inside  the  cells  of  the 
microprogram  ROM  is  simple  for  speed  and  compact  size.  All 
cells  contain  alignment  points  for  easy  assembly  by  a 
silicon  compiler.  The  design  verification  reveals  no  dis¬ 
crepancies  between  the  design  and  the  controller  goals  and 
requirements . 


VII.  CONTROLLER  IMPLEMENTATION 


Implementation  of  the  microprogrammed  controller  for  MSC 
involves  many  interrelated  tasks  including:  installation  of 
the  MSC  software  on  the  ISI  workstations,  upgrade  of  MSC  for 
SCMOS  technology  and  compatibility  with  the  Magic1  VLSI  lay¬ 
out  editor,  cell  layout  and  test,  addition  of  cells  to  MSC, 
and  extension  of  MSC  to  use  the  new  cells.  Addition  of  the 
cells  to  MSC  and  extension  of  MSC  for  the  new  cells  are  not 
completed  in  this  thesis  and  will  require  further  research. 

A.  MSC  SOFTWARE  INSTALLATION 

Implementation  of  the  microprogrammed  controller  for  MSC 
started  with  installation  of  the  MacPitts  software  on  a 
clustered  set  of  three  ISI  workstations.  During  the  process 
of  installation,  MacPitts  was  updated  to  use  the  Franz  Lisp 
interpreter  Opus  38.78  and  the  Liszt  compiler  Opus  8.36  with 
BSD  4.2  UNIX.  During  the  installation,  many  errors  were 
corrected  to  produce  error  and  warning  free  compilations. 
Additional  modifications  were  performed  to  permit  use  of  the 
Franz  Lisp  trace,  stepping,  and  debugging  programs.  A  log 
of  all  actions  taken  during  installation  is  contained  in  Ap¬ 
pendix  A. 

1The  Magic  VLSI  layout  editor  is  described  in  1986  VLSI 
Tools:  Still  More  Works  bv  the  Original  Artists  (UCB/CSD 


86/272,  December  1985). 


B.  MSC  MAGIC  AND  SCMOS  UPGRADE 


The  CIF  output  produced  by  the  original  MacPitts  silicon 
compiler  was  not  compatible  with  the  Magic  VLSI  layout  edi¬ 
tor.  Since  Magic  is  the  primary  VLSI  layout  editor  used  at 
the  Naval  Postgraduate  School,  the  silicon  compiler  had  to 
be  modified  to  work  with  Magic.  An  additional  benefit  of 
Magic  compatibility  is  that  the  Magic  program  can  extract 
simulation  information  for  use  by  the  ESIM2  event  driven 
switch  level  simulator  and  the  CRYSTAL3  VLSI  timing  ana¬ 
lyzer.  The  modifications  to  MacPitts  to  produce  Magic  CIF 
are  in  Software  Change  Proposal  SCP-1.  SCP-1  is  superseded 
by  SCP-2  and  is  not  included  in  this  thesis. 

The  original  version  of  MacPitts  supports  a  single  four 
or  five  micron  nMOS  technology.  By  adding  SCMOS  layers  to 
the  nMOS  layers  in  MacPitts,  a  CIF  file  may  be  produced  that 
has  both  SCMOS  and  nMOS  layers.  However,  this  hybrid  tech¬ 
nology  is  not  suitable  for  simulation  or  fabrication.  Also, 
use  of  this  technique  to  add  new  technologies  to  the  silicon 
compiler  would  require  a  complete  new  silicon  compiler  pro¬ 
gram  for  each  technology.  A  more  flexible  solution  is  to 
add  command  line  options  to  the  silicon  compiler  to  select 

2The  ESIM  event  driven  switch  level  VLSI  simulator  is 
described  in  1986  VLSI  Tools:  Still  More  Works  bv  the  Orig¬ 
inal  Artists  (UCB/CSD  86/272,  December  1985). 

3The  CRYSTAL  VLSI  timing  analyzer  is  described  in  1986 
VLSI  Tools:  Still  More  Works  bv  the  Original  Artists 
(UCB/CSD  86/272,  December  1985). 


't 


the  technology  to  be  used  for  CIF  output.  The  modifications 
to  MacPitts  to  add  the  required  command  line  options  is  in 
Software  Change  Proposal  SCP-2.  SCP-2  supersedes  SCP-1  and 
is  presented  in  Appendix  2.  SCP-2  was  approved  and  incorpo¬ 
rated  in  the  MSC  baseline.  The  modifications  in  SCP-2 
enable  establishment  of  an  integrated  silicon  compiler 
development  environment  that  includes  the  MSC  silicon  com¬ 
piler  including  an  internal  functional  simulator  and  Franz 
Lisp  stepping,  tracing,  and  debugging  programs,  the  Magic 
VLSI  layout  editor,  the  ESIM  event  driven  switch  level  simu¬ 
lator,  and  the  CRYSTAL  VLSI  timing  analyzer. 


C.  CELL  LAYOUT  AND  TEST 

All  cells  described  in  Chapter  VI  have  been  laid  out  us¬ 
ing  the  Magic  VLSI  layout  editor.  Each  cell  passes  the  in¬ 
ternal  Magic  design  rule  checker.  An  extraction  file  for 
each  cell  has  been  produced  by  using  the  Magic  extract  com¬ 
mand.  The  extraction  files  have  been  converted  into  simula¬ 
tion  files  by  the  ext2sim4  program.  Each  simulation  file 
was  tested  with  the  CRYSTAL  static  circuit  check  and  ESIM 
event  driven  switch  level  simulator  to  verify  proper  perfor¬ 
mance.  A  test  microprogram  ROM  named  ROMtest.mag  contains 
all  of  the  Chapter  VI  cells  with  all  abutments,  overlaps, 
and  orientations  that  are  possible  for  the  microprogram  ROM 

4The  ext2sim  program  is  described  in  1986  VLSI  Tools: 
Still  More  Works  bv  the  Original  Artists  (UCB/CSD  86/272, 
December  1985) . 
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floor  plan  in  Figure  6.5.  The  combinations  of  cells  in 
ROMtest.mag  also  pass  the  internal  Magic  design  rule 
checker.  The  simulation  file  ROMtest.sim  is  also  produced 
by  using  the  Magic  extract  command  to  produce  extraction 
files  for  each  cell  in  ROMtest.mag  and  merging  these  extrac¬ 
tion  files  using  the  ext2sim  program.  ROMtest.sim  passes 
the  CRYSTAL  static  electrical  check  and  produces  critical 
paths  that  correspond  to  the  intended  operation  of  the  cir¬ 
cuit.  Using  the  ESIM  event  driven  switch  level  simulator, 
ROMtest.sim  produces  correct  outputs  for  all  inputs.  Proper 
operation  of  each  cell  and  combination  of  cells  is  assured 
by  this  simulation. 

D.  ADDITION  OF  CELLS  TO  MSC 

Defsymbols  named  layout-romO  and  layout-roml  for  the 
ROMO  and  ROMl  cells  are  contained  in  the  file  controller . 1 . 
This  file  has  been  loaded  into  a  test  version  of  MSC  and 
used  to  generate  test  layouts.  The  test  layouts  have  been 
loaded  into  Magic  and  pass  the  internal  design  rule  checker. 
Addition  of  the  remainder  of  the  cells  to  MSC  is  not  com¬ 
pleted  in  this  thesis  and  will  require  further  research. 

The  defsymbols  were  produced  manually  from  the  original 
Magic  layouts.  This  same  procedure  could  be  used  to  add  the 
remainder  of  the  cells  into  MSC.  Another  method  to  load  the 
cells  into  MSC  would  be  to  write  a  program  that  generates  a 
defsymbol  definition  from  a  Magic  or  cif  file.  This  process 


has  been  used  in  other  thesis  research  to  enter  cells  into 
MSC.  The  final  result  of  either  procedure  is  a  large  pro¬ 
gram  that  is  technology  dependent.  To  add  a  new  feature  or 
new  technology  to  MSC  using  these  procedures  will  require 
major  revision  of  the  MSC  program. 

A  better  way  to  add  new  features,  cells,  or  technologies 
to  MSC  is  to  develop  a  mechanism  in  MSC  to  use  cells  that 
are  not  part  of  the  MSC  program.  One  way  to  implement  this 
mechanism  involves  two  new  programs. 

One  program  can  be  written  in  C  or  any  other  language  to 
convert  a  cif  file  into  a  form  that  is  easily  read  by  the 
Franz  Lisp  interpreter.  This  program  would  produce  a  file 
that  is  formatted  as  a  lisp  list.  This  file  would  contain 
the  bounding  box  of  the  cell,  all  required  labels  for  the 
cell,  and  all  layout  information  for  the  cell.  All  measure¬ 
ments  would  be  converted  to  lambda  units  so  that  MSC  can 
scale  them  to  the  appropriate  minimum  feature  size.  The  po¬ 
sition  of  the  cell  would  be  translated  to  a  home  position. 
The  lisp  formatted  files  would  be  stored  in  separate  direc¬ 
tories  for  each  technology. 

The  second  program  would  be  an  additional  macro  to  MSC 
named  cif symbol  that  is  similar  to  the  def symbol  macro. 
Each  cell  used  by  the  compiler  would  be  defined  by  a  cifsym- 
bol  definition.  The  cifsymbol  contains  the  name  of  the  cell 
and  the  names  of  any  required  labels  in  the  cell.  The  cif¬ 
symbol  does  not  contain  any  technology  information.  If  the 


cif symbol  is  not  used,  it  is  not  expanded  and  the  program 
stays  small.  The  first  time  the  cif  symbol  is  called,  the 
macro  is  expanded.  When  the  macro  is  expanded,  a  set  of  di¬ 
rectories  specified  for  the  MSC  technology  is  searched  for 
the  lisp  file  corresponding  to  the  cell  name.  When  the  cell 
file  is  found,  it  is  read  and  immediately  output  to  the 
— L5-symbol-list  file.  The  cif symbol  call  returns  a  symbol 
that  calls  the  cell.  This  symbol  does  not  contain  layout 
information.  All  subsequent  calls  to  the  cif symbol  return 
similar  symbols  and  do  no  other  processing. 

This  cifsymbol  method  will  significantly  reduce  the  size 
of  the  MSC  program,  remove  technology  dependent  structures 
from  the  MSC  program,  and  increase  the  efficiency  of  devel¬ 
oping  new  cells  or  modifying  existing  cells  that  are  part  of 
MSC.  To  replace  an  existing  cell  for  MSC,  a  user  would  sim¬ 
ply  have  a  file  in  a  directory  earlier  in  the  search  path 
with  the  same  name  as  the  cell  being  replaced. 

E.  MSC  CONTROLLER  EXTENSION 

Adding  the  microprogrammed  controller  to  MSC  will  re¬ 
quire  a  modification  of  the  object  file  structure  and 
changes  to  the  extract. 1  and  control. 1  programs,  and  the  ad¬ 
dition  of  a  single  bit  data-path.  These  extensions  of  MSC 
are  not  completed  in  this  thesis  and  will  require  further 


research . 


The  current  nMOS  object  file  structure  has  five  ele¬ 
ments  for  definitions,  flags,  data-path,  control,  and  pins. 
The  control  element  contains  specifications  for  a  NOR  gate 
based  Weinberger  control  logic  array.  The  microprogrammed 
controller  object  file  control  element  should  contain  speci¬ 
fications  for  a  microprogram  ROM.  These  specifications  will 
include  the  number  of  processes,  the  number  of  states  in 
each  process,  the  number  of  cond  statements,  the  number  of 
substates  in  each  cond  statement,  the  sources  of  test  inputs 
for  each  cond  substate,  and  the  ROM  contents  for  each  state 
and  substate . 

2.  Extract. 1  Modifications 

The  functions  in  the  extract. 1  program  that  produce 
the  object  file  control  element  must  be  modified  to  produce 
the  new  structure  described  in  Section  VII. E.l. 


3 .  Extraction  Example 

This  section  provides  an  example  of  the  functions 
that  must  be  performed  by  the  modified  extract. 1  to  derive 
the  information  required  for  the  new  object  file  control  el¬ 
ement.  This  example  is  based  on  the  following  taxi  cab  me¬ 
ter  design  specification  presented  in  An  Introduction  to 
MacPitts  (MIT  RVLSI-3,  pp.  13-29,  10  February  1983). 

(program  taxi  8 
(def  17  power) 

(def  1  ground) 

(def  2  phia) 

(def  3  phib) 


(def  4  phic) 

(def  timer  register) 

(def  fare  register) 

(def  reset  signal  input  5) 

(def  time-on  signal  input  6) 

(def  hire  signal  input  7) 

(def  mile-mark  signal  input  8) 

(def  display  port  tri-state  (9  10  11  12  13  14  15  16)) 

(def  charge-time  signal  internal) 

(def  maximum-time  constant  100) 

(def  base-fare  constant  20) 

(def  cost-per-mile  constant  50) 

(def  cost-per-time  const  10) 

(process  time-clock  0 
off 

(cond  (time-on  (setq  timer  0)  (go  on)) 

(t  (go  off))) 
on 

(cond  (time-on  (cond  ( (=  timer  maximum-time) 

(setq  timer  0) 

(signal  charge-time)) 

(go  on)) 

(t  (setq  timer  0)  (go  off)))) 

(process  fare-clock  0 
for-hire 

(cond  (hire  (setq  fare  base-fare)  (go  hired)) 

(t  (go  for-hire))) 

hired 

(par  (cond  ((not  hire)  (go  for-hire)) 

( (and  charge-time  mile-mark) 

(setq  fare  (+  (+  fare  cost-per-mile) 
cost-per-time) ) 

(go  hired) ) 

(charge-time 

(setq  fare  (+  fare  cost-per-time)) 

(go  hired) ) 

(mile-mark 

(setq  fare  (+  fare  cost-per-mile)) 

(go  hired) ) 

(t  go  hired) ) ) 

(setq  display  fare)))) 

There  are  two  processes  in  the  taxi  program.  Each 
process  will  have  its  own  row  decoder.  The  first  process  is 
named  time-clock  and  it  has  two  states  named  off  and  on. 
The  second  process  is  named  fare-clock  and  it  has  two  states 


named  for-hire  and  hired.  The  modified  control. 1  will  use 
Two-State  cells  for  the  row  decoder  for  each  process. 

There  are  five  cond  statements  in  the  program.  The 
modified  control. 1  program  will  layout  each  cond  statement 
as  a  cond  group  in  accordance  with  the  design  in  Section 
VI. D. 3. 

The  first  cond  statement  has  two  substates.  The 
test  input  for  the  first  substate  is  the  input  signal  time- 
on.  The  second  substate  is  always  true  so  there  is  no  in¬ 
put.  The  modified  control. 1  will  use  the  CONDtrue  cell  for 
this  substate. 

The  second  cond  statement  has  two  substates .  The 
test  input  for  the  first  substate  is  the  input  signal  time- 
on.  The  second  substate  is  always  true  so  there  is  no  in¬ 
put.  The  modified  control. 1  will  use  the  CONDtrue  cell  for 
this  substate. 

The  third  cond  statement  has  two  substates.  The 
test  input  for  the  first  substate  is  the  test  line  from  the 
=  organelle  in  the  data-path.  The  second  substate  is  always 
true  so  there  is  no  input.  The  modified  control. 1  will  use 
the  CONDtrue  cell  for  this  substate. 

The  fourth  cond  statement  has  two  substates.  The 
test  input  for  the  first  substate  is  the  input  signal  hire. 
The  second  substate  is  always  true  so  there  is  no  input. 
The  modified  control.  1  will  use  the  CONDtrue  cell  for  this 
substate. 
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The  fifth  cond  statement  has  five  substates.  The 
test  input  for  the  first  substate  is  the  internal  signal 
from  a  not  organelle  in  the  single  bit  data-path.  The  input 
to  this  organelle  is  the  external  signal  hire.  The  test  in¬ 
put  for  the  second  substate  is  the  internal  signal  from  an 
and  organelle  in  the  single  bit  data-path.  The  inputs  to 
this  organelle  are  the  internal  signal  charge-time  and  the 
external  signal  mile-mark.  The  test  input  for  the  third 
substate  is  the  internal  signal  charge-time.  The  test  input 
for  the  fourth  substate  is  the  input  signal  mile-mark.  The 
fifth  substate  is  always  true  so  there  is  no  input.  The 
modified  control.  1  will  use  the  CONDtrue  cell  for  this 
substate. 

The  following  is  the  object  file  data-path  element 
generated  by  the  current  MSC  for  the  taxi  program: 

((register  sequencer-time-clock-state  -l 

(((constant  0))  ((internal  2)))) 

(port- internal  sequencer-time-clock-next-state  -2 

(((constant  1))  ((constant  0)))) 

(bit  (0)  (((internal  1)))) 

(register  timer  -3  (((constant  0))  ((internal  4)))) 
(organelle  =  0  (((internal  3)  (constant  100)))) 

(organelle  |l+|  -4  (((internal  3)))) 

(register  sequencer-fare-clock-state  -5 

(((constant  0))  ((internal  6)))) 
(port-internal  sequencer-fare-clock-next-state  -6 

(((constant  1))  ( (constantO) ) ) ) 

(bit  (0)  (((internal  5)))) 

(port-output  display  (((internal  7)))) 

(register  fare  -7 

(((constant  20))  ((internal  9))  ((internal  8)))) 
(organelle  +  -8 

(((internal  7  (constant  50)) 

((internal  7)  (constant  10)))) 

(organelle  +  -9  (((internal  8)  (constant  10))))) 


Each  element  in  this  list  corresponds  to  a  unit  in 
the  data-path.  If  the  layout  of  the  circuit  is  oriented  so 
that  the  data-path  is  at  the  top,  the  first  element  corre¬ 
sponds  to  the  left  unit  in  the  data-path.  The  data-path  for 
the  taxi  program  has  thirteen  units.  This  list  can  be  used 
to  determine  the  names  and  the  order  of  the  multiplexer  con¬ 
trol  lines  and  test  signal  lines  between  the  data  path  and 
the  controller.  The  multiplexer  control  lines  will  corre¬ 
spond  to  columns  in  the  microprogram  ROM. 

The  input  element  in  a  unit  specification  determines 
the  input  multiplexer  configuration  of  that  unit.  The  input 
element  is  the  fourth  element  in  register,  internal  port, 
and  organelle  unit  specifications  and  the  third  element  in 
bit  and  output  port  unit  specifications.  The  input  element 
is  always  a  list.  If  the  list  has  a  single  element,  there 
is  only  one  set  of  inputs  to  the  unit  that  are  connected  to 
a  degenerate  multiplexer  and  there  are  no  multiplexer  con¬ 
trol  lines.  If  there  is  more  than  one  element  in  the  list, 
the  number  of  elements  is  the  number  of  multiplexer  control 
lines.  Each  element  of  the  list  in  the  input  element  is  a 
list  of  inputs  that  are  enabled  when  the  control  line  for 
this  element  is  high.  There  are  internal  and  constant  in¬ 
puts.  An  internal  input  comes  from  an  internal  bus.  A  con¬ 
stant  input  is  generated  by  connecting  the  inputs  to  the 
multiplexer  to  power  or  ground. 


All  units  may  have  multiplexer  control  lines.  Reg¬ 
ister  units  have  an  enable  control  line  that  determines 
whether  or  not  the  register  contents  are  allowed  to  be  up¬ 
dated  during  state  transition.  Bit  units  have  test  lines 
that  are  used  to  provide  single  bit  outputs  to  the  con¬ 
troller.  Organelle  units  may  have  test  lines  and  carry  in¬ 
put  lines  depending  on  the  function  of  the  organelle.  The 
organelle  unit  test  lines  and  carry  lines  may  not  be  con¬ 
nected  to  the  controller. 

The  first  unit  in  the  data-path  is  a  register  for 
sequencer-time-clock-state.  This  register  contains  the 
state  number  for  the  time-clock  process.  The  -1  for  the 
third  element  in  the  register  specification  states  that  the 
output  of  the  register  is  connected  to  internal  bus  1.  The 
fourth  element  is  a  list  that  has  two  elements.  This  means 
that  there  are  two  multiplexer  control  lines  for  this  unit 
named  (mpx  1  1)  and  (mpx  1  2).  The  second  element  in  the 
multiplexer  name  is  the  unit  number.  The  multiplexer  con¬ 
trol  line  (mpx  1  1)  enables  a  constant  input  of  0  for  the 
unit  and  (mpx  1  2)  enables  an  input  from  internal  bus  2. 
The  left  line  is  (mpx  1  2)  and  the  right  line  is  (mpx  1  1)  . 
The  (mpx  1  1)  control  line  is  connected  to  the  external  re¬ 
set  signal  to  force  the  contents  of  the  register  to  0.  This 
multiplexer  selection  must  override  any  other  multiplexer 
selections.  This  would  violate  the  requirement  for  true 
multiplexers.  A  better  solution  is  to  use  a  register  that 


has  a  reset  input.  This  input  would  be  connected  to  the  re¬ 
set  input  signal.  To  the  right  of  the  multiplexer  control 
lines  is  an  enable  control  line  for  the  register  named 
(control-line  1  1) .  When  this  line  is  high,  it  enables 
loading  of  the  register. 

The  second  unit  in  the  data-path  is  an  internal  port 
for  sequencer-time-clock-next-state.  This  port  generates 
the  next  state  numbers  for  the  time-clock  process.  The  -2 
for  the  third  element  in  the  internal  port  specif ication 
states  that  the  output  of  the  internal  port  is  connected  to 
internal  bus  2.  The  fourth  element  is  a  list  that  has  two 
elements.  This  means  that  there  are  two  multiplexer  control 
lines  for  this  unit  named  (mpx  2  1)  and  (mpx  2  2) .  The  sec¬ 
ond  element  in  the  multiplexer  name  is  the  unit  number.  The 
multiplexer  control  line  (mpx  2  1)  enables  a  constant  input 
of  1  for  the  unit  and  (mpx  2  2)  enables  a  constant  input  of 
0.  The  left  line  is  (mpx  2  2)  and  the  right  line  is  (mpx  2 
1)  .  When  (mpx  2  1)  is  high,  the  next  state  is  on  and  when 
(mpx  22)  is  high,  the  next  state  is  off. 

The  third  unit  in  the  data-path  is  a  bit  unit.  This 
unit  extracts  bit  0  from  its  input  word.  The  third  element 
is  a  list  that  has  one  elements.  This  means  that  this  bit 
unit  has  a  single  input  source.  As  a  result,  there  are  no 
multiplexer  control  lines  for  this  unit.  The  input  is  con¬ 
nected  directly  to  internal  bus  1.  Since  this  unit  is  for  a 


single  bit,  it  has  a  single  test  line  (test-line  3  1)  that 
returns  the  bit  to  the  controller. 

These  first  three  units  form  a  no-counter-no-stack 
sequencer  for  the  first  process. 

The  fourth  unit  is  a  register  for  the  timer.  The 
output  of  the  register  is  connected  to  internal  bus  1.  The 
register  has  two  multiplexer  control  lines  and  an  enable 
control  line  named  (mpx  4  1) ,  (mpx  4  2) ,  and  (control-line  4 
1)  • 

The  fifth  unit  is  an  =  organelle  unit.  Since  the 
fourth  element  of  the  organelle  specification  is  a  list  with 
a  single  element  that  is  a  list  of  two  elements,  this  unit 
has  two  inputs  with  one  signal  for  each  input.  The  inputs 
are  connected  to  internal  bus  3  and  the  constant  100.  This 
unit  does  not  have  any  multiplexer  control  lines.  The  unit 
has  a  single  test  line  (test-line  5  1)  that  is  connected  to 
the  controller.  This  signal  is  high  when  the  internal  bus 
3,  the  output  of  the  timer  register,  is  equal  to  100. 

The  sixth  unit  is  a  1+  organelle  unit.  This  is  an 
incrementer  that  has  internal  bus  4  for  output  and  internal 
bus  3  for  input.  This  incrementer  unit  has  no  multiplexer 
control  lines  and  a  single  test  line  (test-line  6  1) .  This 
test  line  is  high  when  there  is  a  carry  out  of  the  most  sig¬ 
nificant  bit  of  the  incrementer.  This  test  line  is  not  con¬ 
nected  to  the  controller. 


Units  seven,  eight,  and  nine  form  a  no-counter-no¬ 
stack  sequencer  for  the  second  process.  Their  configuration 
is  similar  to  units  one,  two,  and  three.  The  (mpx  7  1)  mul¬ 
tiplexer  control  line  is,  connected  to  the  external  reset 
signal . 

Unit  ten  is  a  port-output  unit  for  the  display  out¬ 
put  port.  The  input  of  this  unit  is  connected  to  internal 
bus  7  and  the  output  is  connected  to  lines  below  the  inter¬ 
nal  bus  lines  that  bring  the  output  of  the  unit  to  the  left 
of  the  data-path  and  from  there  to  the  pads.  There  are  no 
multiplexer  control  lines  or  test  lines  for  this  unit. 

The  eleventh  unit  is  a  register  for  the  fare.  The 
output  of  the  register  is  connected  to  internal  bus  7.  The 
register  has  three  multiplexer  control  lines  and  an  enable 
control  lines  named  (mpx  11  1),  (mpx  11  2),  (mpx  11  3),  and 
(control-line  11  1) . 

The  twelfth  unit  is  a  +  organelle  unit.  This  or¬ 
ganelle  unit  contains  a  two  input  full  adder.  This  unit  has 
two  multiplexer  control  lines.  The  (mpx  12  1)  control  line 
enables  the  internal  bus  7  and  constant  50  inputs  to  the 
adder.  The  (mpx  12  2)  control  line  enables  the  internal  bus 
7  and  constant  10  inputs  to  the  adder.  The  output  of  the 
unit  is  connected  to  internal  bus  8.  The  unit  has  a  carry 
out  test  line  that  is  not  connected  to  the  controller. 

The  thirteenth  unit  is  a  +  organelle  unit.  This  or¬ 
ganelle  unit  contains  a  two  input  full  adder.  This  unit  has 


a  single  set  of  inputs  and  no  multiplexer  control  lines. 
The  adder  inputs  are  connected  to  internal  bus  8  and  con¬ 
stant  10  inputs.  The  output  of  the  adder  is  connected  to 
internal  bus  9.  The  unit  has  a  carry  out  test  line  that  is 
not  connected  to  the  controller. 

The  columns  in  the  microprogram  ROM  should  be  in  the 
same  order  as  the  multiplexer  control,  register  enable,  and 
carry  input  lines  from  the  controller  to  the  data-path.  Ad¬ 
ditional  columns  are  required  for  each  cond  enable  and  for 
signals  that  are  generated  by  the  controller.  A  signal  gen¬ 
erated  by  the  controller  has  the  form  (signal  signal-name) 
in  the  program  specification.  One  design  would  have  the 
cond  enable  columns  on  the  left  of  the  ROM,  the  signals  gen¬ 
erated  by  the  controller  in  the  center  of  the  ROM,  and  the 
multiplexer  control,  register  enable,  and  carry  input  lines 


for  the  data-path  on  the  right.  Using  this  design,  the  23 
columns  of  the  ROM  from  left  to  right  would  be: 


cond  enable 
cond  enable 
cond  enable 
cond  enable 
cond  enable 
charge-time 
(mpx  1  2) 
(control-line 
(mpx  2  2) 

(mpx  2  1) 

(mpx  4  2) 

(mpx  4  1) 
(control-line 
(mpx  7  2) 
(control-line 
(mpx  8  2) 

(mpx  8  1) 


1  1) 


4  1) 


7  1) 
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(mpx  11  3) 

(mpx  11  2) 

(mpx  11  1) 

(control-line  11  1) 

(mpx  12  2) 

(mpx  12  1) 

The  rows  of  the  ROM  correspond  to  the  states  of  the 

processes  and  the  substates  of  the  conds.  This  produces  the 

following  rows  for  the  ROM  from  top  to  bottom: 

process  time-clock  state  off 
process  time-clock  state  on 
process  fare-clock  state  for-hire 
process  fare-clock  state  hired 
cond  1  substate  time-on 
cond  1  substate  t 
cond  2  substate  time-on 
cond  2  substate  t 

cond  3  subsubstate  (=  timer  maximum-time) 

cond  3  subsubstate  t 

cond  4  substate  hire 

cond  4  substate  t 

cond  5  substate  (not  hire) 

cond  5  substate  (and  charge-time  mile-mark) 

cond  5  substate  charge-time 

cond  5  substate  mile-mark 

cond  5  substate  t 

All  of  the  multiplexer  control,  register  enable,  and 
carry  input  lines  for  each  unit  are  associated  with  a  single 
process.  The  time-clock  process  has  control  of  the  first, 
second,  and  fourth  units,  the  charge-time  signal,  and  the 
first  three  conds.  The  fare-clock  process  has  control  of 
the  seventh,  eighth,  eleventh,  and  twelfth  units  and  the 
last  two  conds.  Each  ROM  column  associated  with  signals 
controlled  by  a  process  must  be  set  to  a  1  or  a  0  in  every 
valid  combination  of  states  and  substates  of  that  process. 
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This  information  can  be  used  to  derive  the  contents  of  the 
microprogram  ROM. 

The  top  row  of  the  ROM  is  assigned  to  the  off  state 
of  the  time-clock  process.  In  this  state,  the  first  cond  is 
enabled  and  the  second  and  third  conds  are  not  enabled.  The 
charge-time  signal  is  0.  The  (mpx  1  2)  and  (control-line  1 
1)  are  l  to  load  the  time  clock  state  register  from  the  in¬ 
ternal  port  (second)  unit.  If  a  hyphen  is  used  to  represent 
a  null  entry  in  the  microprogram  ROM,  the  top  row  of  the  ROM 
is: 

100 - Oil - 

The  second  row  of  the  ROM  is  assigned  to  the  on 
state  of  the  time-clock  process.  In  this  state,  the  first 
cond  is  not  enabled  and  the  second  cond  is  enabled.  The 
third  cond  is  controlled  by  the  second  cond.  The  charge¬ 
time  signal  is  controlled  by  the  third  cond.  The  (mpx  1  2) 
and  (control-line  l  l)  are  1  to  load  the  time  clock  state 
register  from  the  internal  port  (second)  unit.  The  second 
row  of  the  ROM  is: 

01 - 11 - 

The  third  row  of  the  ROM  is  assigned  to  the  for-hire 
state  of  the  fare-clock  process.  In  this  state,  the  fourth 
cond  is  enabled  and  the  fifth  cond  is  not  enabled.  The  (mpx 
7  2)  and  (control-line  7  1)  are  1  to  load  the  fare  clock 


state  register  (seventh  unit)  from  the  internal  port 
(eighth)  unit.  The  third  row  of  the  ROM  is: 

- 10 - 11 - 

The  fourth  row  of  the  ROM  is  assigned  to  the  hired 
state  of  the  fare-clock  process.  In  this  state,  the  fifth 
cond  is  enabled  and  the  fourth  cond  is  not  enabled.  The 
(mpx  7  2)  and  (control-line  7  1)  are  1  to  load  the  fare 
clock  state  register  (seventh  unit)  from  the  internal  port 
(eighth)  unit.  The  fourth  row  of  the  ROM  is: 

- 01 - 11 - 

The  fifth  row  of  the  ROM  is  assigned  to  the  time-on 
substate  of  the  first  cond.  In  this  substate,  the  next 
state  internal  port  (second  unit)  is  set  to  generate  a  1  for 
the  on  state  so  (mpx  2  1)  is  1  and  (mpx  2  2)  is  o.  The 
timer  register  (fourth  unit)  is  set  to  0  so  (mpx  41)  is  1, 
(mpx  4  2)  is  0  and  (control -line  4  1)  is  1.  The  fifth  row 
of  the  ROM  is: 

- 01011 - 

The  sixth  row  of  the  ROM  is  assigned  to  the  t  sub¬ 
state  of  the  first  cond.  In  this  substate,  the  next  state 
internal  port  (second  unit)  is  set  to  generate  a  0  for  the 
off  state  so  (mpx  2  1)  is  0  and  (mpx  2  2)  is  1.  The  timer 
register  (fourth  unit)  does  not  change  so  (control-line  4  l) 
is  0.  The  sixth  row  of  the  ROM  is: 


The  seventh  row  of  the  ROM  is  assigned  to  the  time- 
on  substate  of  the  second  cond.  In  this  substate,  the  third 
cond  is  enabled.  The  next  state  internal  port  (second  unit) 
is  set  to  generate  a  1  for  the  on  state  so  (mpx  2  1)  is  1 
and  (mpx  2  2)  is  0.  The  timer  register  (fourth  unit)  is 
loaded  in  all  subsubstates  of  this  substate  so  (control-line 
4  1)  is  1.  The  seventh  row  of  the  ROM  is: 

The  eighth  row  of  the  ROM  is  assigned  to  the  t  sub¬ 
state  of  the  second  cond.  In  this  substate,  the  third  cond 
is  not  enabled.  The  next  state  internal  port  (second  unit) 
is  set  to  generate  a  1  for  the  on  state  so  (mpx  2  1)  is  1 
and  (mpx  2  2)  is  0.  The  timer  register  (fourth  unit)  is 
loaded  to  0  so  (mpx  41)  is  1,  (mpx  42)  is  0,  and  (control¬ 
line  41)  is  1.  The  eighth  row  of  the  ROM  is: 

- 0 - - -01011 - - 

The  same  process  can  be  used  for  the  remainder  of 
the  rows.  The  full  microprogram  ROM  is  shown  in  Figure  7.1. 

4 .  Control. 1  Modifications 

The  functions  in  the  control. 1  program  must  be  modi¬ 
fied  to  produce  a  microprogram  ROM  from  the  new  object  file 
control  element  structure  described  in  Section  VII. E.l 

5.  Single  Bit  Data-Path 

The  current  nMOS  MSC  performs  all  single  bit  pro¬ 
cessing  in  the  Weinberger  control  logic  array.  The  library 
program  contains  macros  that  convert  all  single  bit 
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Figure  7.1  Taxi  Microprogram  ROM  Design 


functions  into  combinations  of  NOR  functions  that  are 


specified  in  the  object  file  control  element.  These 


functions  cannot  be  accomplished  by  a  microprogrammed 


controller.  A  set  of  cells  for  single  bit  functions  are 


required  and  an  area  for  single  bit  processing  must  be  added 


to  the  MSC  floor  plan. 


IMPLEMENTATION  STATUS 


The  cells  specified  in  Chapter  VI  are  laid  out  and 


tested.  A  microprogrammed  controller  constructed  from  these 


cells  and  using  sequencers  constructed  from  data  path  units 


will  be  able  to  fulfill  all  MSC  controller  requirements 


VIII.  CONTROLLER  TESTING 


After  completion  of  the  microprogrammed  controller  im¬ 
plementation  described  in  Chapter  VII,  the  resulting  silicon 
compiler  will  require  extensive  testing.  A  series  of  bench¬ 
mark  design  specifications  will  have  to  be  generated  that 
test  all  types  of  controller  configurations.  These  bench¬ 
marks  should  include  designs  that  have  multiple  processes, 
nested  cond  statements,  processes  with  many  states,  con¬ 
troller  generated  signals,  counter-stack  sequencers, 
counter-no-stack  sequencers,  and  no-counter-no-stack  se¬ 
quencers.  Each  of  the  benchmarks  should  be  exercised  using 
the  MSC  internal  design  interpreter  and  the  simulated  out¬ 
puts  produced  by  test  inputs  should  be  recorded.  Each 
benchmark  design  should  then  be  output  in  Magic  cif  format. 
The  cif  files  should  be  loaded  into  Magic  and  verified  using 
the  Magic  internal  design  rule  checker.  Simulation  files 
should  be  prepared  by  extracting  the  designs  using  the  Magic 
extract  command  and  converting  the  extract  files  to  simula¬ 
tion  files  with  the  ext2sim  program.  The  circuits  should  be 
checked  with  the  CRYSTAL  static  electrical  check  command. 
Each  simulation  file  should  be  tested  using  the  ESIM  event 
driver  switch  level  simulator  with  the  same  test  inputs  as 
were  used  with  the  MSC  internal  design  interpreter  tests. 
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The  ESIM  simulated  outputs  should  be  the  same  as  the  MSC  in¬ 
ternal  design  interpreter  outputs. 
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IX.  CONCLUSIONS 


A.  CONTROLLER  DESIGN 

A  microprogrammed  controller  for  the  MSC  silicon  com¬ 
piler  has  been  designed  and  tested.  The  remaining  steps  to 
fully  implement  the  controller  have  also  been  described. 
The  design  of  the  controller  followed  a  complete  development 
process.  Requirements  for  the  controller  were  defined,  al¬ 
ternative  technologies  and  organizations  were  analyzed,  a 
technology  and  organization  were  selected,  and  a  design  was 
produced  using  the  selected  technology  and  organization. 
Use  of  a  well  defined  formal  development  process  was  very 
beneficial  to  this  thesis  research. 

B.  MSC  STRUCTURE 

The  current  internal  structure  of  the  MSC  programs  is 
very  technology  dependent.  A  major  reorganization  would  im¬ 
prove  the  addition  of  other  technologies  to  MSC.  The  li¬ 
brary  and  organelles. 1  programs  are  not  permanent  parts  of 
the  MSC  compiler.  They  are  loaded  at  run  time.  There 
should  be  library  and  organelles. 1  programs  that  are  unique 
for  each  technology.  All  of  the  technology  dependent  func¬ 
tions  of  MSC  should  be  moved  to  these  programs.  The  name  of 
the  technology  should  be  added  to  the  beginning  of  each  pro¬ 
gram's  name  or  they  should  be  stored  in  different 
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directories  so  that  the  only  technology  dependent  functions 


loaded  into  MSC  at  run  time  are  those  for  the  selected 


technology. 


C .  ADDITIONAL  RESEARCH 


There  are  several  topics  for  follow-on  research  that  are 


presented  in  this  thesis.  The  most  important  is  the  devel¬ 


opment  of  the  cifsymbol  macro  described  in  Section  VII. D. 


This  would  provide  a  technology  independent  method  for 


adding  cells  to  MSC.  Other  follow  on  research  involves  the 


implementation  and  test  of  the  microprogram  controller  de¬ 


scribed  in  Section  VII. E  and  Chapter  VIII. 


row? 


APPENDIX  A  ISI  INSTALLATION  LOG 


This  file  is  a  log  of  the  procedures  used  to  compile  the 

MacPitts  Silicon  Compiler  on  the  ISI  system  at  NPGS. 

25  Feb  1987  J.  Harmon  and  R.  Limes  loaded  original  source 
files  from  the  computer  science  VAX  installa¬ 
tion  into  the  /usr/macpit  directory. 

25  Feb  1987  J.  Harmon  modified  the  c-routines.c  program  to 

eliminate  the  multiple  definition  problem  for 
the  global  variable  "ospeed" .  This  problem  was 
the  result  of  loading  a  C  language  object  file 
into  Franz  Lisp  or  Liszt  with  a  global  variable 
which  had  the  same  name  as  one  inside  Lisp  or 
Liszt.  MacPitts  was  written  using  an  older 
Opus  of  Franz  that  did  not  have  a  termcap  in¬ 
terface.  The  current  Franz  has  termcap  capa¬ 
bility  that  includes  the  global  variable 
"ospeed"  from  the  file  tputs.o  in  libtermcap. a. 
C-routines.c  uses  the  curses  package  that  in¬ 
cludes  a  global  variable  "ospeed"  in  cr_tty.o 
in  libcurses.a.  The  fix  was  to  include  a  local 
definition  of  the  functions  in  cr_tty.o  in 
libcurses.a.  This  fix  replaces  the  previous 
fix  of  changing  the  lib  files  that  returned  the 
problem  when  Franz  was  recompiled  or  a  new  ver¬ 
sion  of  the  lib  files  was  installed. 

26  Feb  1987  J.  Harmon  modified  lincoln.l  to  remove  compila¬ 

tion  warnings  that  were  caused  by  the  upgrade 
to  the  current  opus  of  Franz  Lisp  and  Liszt. 
Also  corrected  errors  that  caused  compilation 
warnings  in  the  original  opus.  Escaped  all  $ 
characters  so  there  would  not  be  any  trouble  if 
the  back-quote  symbol  is  changed  to  $.  Changed 
remove  to  remove-parameter  since  remove  is  a 
standard  function  in  the  current  opus  of  Lisp. 
Removed  the  path  restriction  on  the  cfasl  of  c- 
routines.o  so  that  a  local  version  may  be  used. 
Declared  fixnum,  list,  predicate,  thing,  and 
grade-predicate  special  for  the  whole  program 
so  that  they  are  special  when  the  macros  that 
use  them  are  evaluated.  Removed  the  pp-form 
function  since  it  used  a  Lisp  primitive  $prpr 
that  is  not  in  the  current  opus.  The  current 
opus  has  its  own  pp-form.  Removed  profane 
language  from  the  err  notice  in  tr-traceexit . 


27  Feb  1987  J.  Hannon  added  all  of  the  changes  written  by 
E.  Malagon  for  L5.  This  included  adding 
messages  to  L5-err,  adding  SCMOS  layers, 
creating  a  hybrid  nMOS/SCMOS  technology,  and 
changing  the  CIF  output  from  to  use  "94” 
extension  for  labels. 

27  Feb  1987  J.  Harmon  compiled  defstructs.l  with  no  errors. 

No  modification  required  for  defstructs.l. 

27  Feb  1987  J.  Harmon  escaped  all  $  characters  in  front¬ 
page.  1  . 

27  Feb  1987  J.  Harmon  compiled  general. 1  with  no  errors. 

No  modification  required  for  general. 1. 

27  Feb  1987  J.  Harmon  escaped  all  $  characters  in  prepass. 1 
and  changed  (argv)  to  (argv  -1)  in  those  cases 
where  it  is  to  return  the  number  of  command 
line  arguments.  This  is  to  conform  with  the 
argv  function  in  the  current  opus  of  Franz 
Lisp. 

27  Feb  1987  J.  Harmon  compiled  extract. 1  with  no  errors. 

No  modification  required  for  extract. 1 

27  Feb  1987  J.  Harmon  compiled  frame. 1  with  no  errors.  No 
modification  required  for  frame. 1. 

27  Feb  1987  J.  Harmon  compiled  data-path.l  with  no  errors. 

No  modification  required  for  data-path.l. 

27  Feb  1987  J.  Harmon  compiled  control . 1  with  no  errors. 

No  modification  required  for  control. 1. 

27  Feb  1987  J.  Harmon  compiled  flags. 1  with  no  errors.  No 
modification  required  for  flags. 1. 

27  Feb  1987  j.  Harmon  compiled  padgen.l  with  no  errors.  No 
modification  required  for  padgen.l. 

27  Feb  1987  J.  Harmon  ran  padgen.l  under  Lisp  to  generate 
pads.l.  Pads.l  does  not  compare  with  the 
distribution  pads.l.  I  will  use  the  version 
generated  in  this  installation  and  not  the 
original  version  that  may  not  be  completely 
compatible  with  the  ISI  installation. 

27  Feb  1987  J.  Harmon  compiled  pads.l  with  no  errors.  The 
pads.l  and  pads.o  files  take  up  a  lot  of  space! 
Disk  is  up  to  99%  full. 


The  disk  was  cleaned  up  so  that  there  now  is 
lots  of  disk  space. 

J.  Hannon  compiled  order. 1  with  no  errors.  No 
modification  required  for  order. 1. 

J.  Harmon  compiled  general. 1  with  no  errors. 

No  modification  required  for  general. 1. 

J.  Harmon  changed  the  name  of  the  function  de¬ 
fined  in  an  .env  file  from  environment  to  env. 
The  environment  function  is  a  built-in  function 
in  the  current  opus  of  Franz  Lisp.  The  env 
function  in  the  .env  file  is  used  to  simulate 
the  environment  outside  the  chip.  If  there  is 
any  outside  processing  of  chip  outputs  to  pro¬ 
duce  chip  inputs,  this  may  be  automatically 
done  by  the  env  function.  This  processing  is 
enabled/disabled  by  the  e  command  to  the  inter¬ 
preter.  The  env  function  is  defined  by  a  defun 
in  the  .env  file  and  has  an  argument  list  of 
(clocked?  new-states  word-length  definitions) 
where  clocked?  is  a  flag  that  is  1 t  if  the  up¬ 
date  is  a  clock  cycle  update  and  ' f  if  the  up¬ 
date  is  a  propagate  update.  New-states  are  the 
current  states  for  the  simulator,  word-length 
is  the  data  path  word  size,  and  definitions  is 
a  list  of  design  definitions  extracted  from  the 
design  specification.  The  function  env  returns 
a  list  of  new-states.  The  port-state-value  or 
signal-state-value  of  the  new-state  is  the 
value  produced  by  the  environment  for  that  in¬ 
put.  The  port-state-driver  or  signal-state- 
driver  must  be  set  to  'environment.  If  a  new- 
state  is  not  returned  that  had  been  previously 
returned  by  a  call  to  env,  the  system  will  re¬ 
turn  control  of  the  signal  to  the  chip.  An  env 
may  not  update  a  signal  or  port  that  is  stable 
and  set  by  the  chip.  If  the  port-state-driver 
or  signal-state-driver  for  the  old  state  is 
'chip  then  the  port-state-value  or  signal- 
state-value  must  be  'unset  for  the  env  to  up¬ 
date  the  input  port  or  signal. 

J.  Harmon  compiled  organelles. 1  with  no  errors. 
No  modification  required  for  organelles. 1 . 

J.  Harmon  replaced  all  #  symbols  with  the  word 
'•number''  and  appropriate  hyphens  in  control.  1, 
data-path.l,  defstructs. 1 ,  extract. 1,  frame. 1, 
front-page.l,  general. 1,  interpret.!, 


lincoln.l,  order. 1,  organelles. 1,  and  Library. 
The  #  symbol  is  used  in  the  reader  as  the 
vspl icing -macro  character.  The  old  version  of 
MacPitts  removed  the  special  use  of  this  sym¬ 
bol.  The  debugger  and  stepper  do  use  this 
symbol  so  this  violation  of  standard  syntax 
interfered  with  the  use  of  the  debugger  and 
stepper. 


10  Mar  1987  J.  Harmon  renamed  function  number-of-tracks  in 
control. 1  to  find-number-of -tracks  to  avoid 
confusion  with  new  variable  named  number- 
tracks.  Note:  there  is  a  local  variable  used 
many  times  in  organelles. 1  that  is  called 
number-of-tracks  and  a  function  called 
determine-number-of -tracks.  These  two 
functions  in  control. 1  and  organelles. 1  should 
probably  be  combined  and  placed  in  general. 1. 


10  Mar  1987  J.  Harmon  replaced  the  name  track-number  in  or¬ 
ganelles.  1  with  the  name  organelles-track-num- 
ber  to  prevent  conflict  with  variables  now 
named  track-number  in  other  sections  of 
MacPitts. 


10  Mar  1987  J.  Harmon  replaced  alpha  form  with  mapcar  form 
in  Library  for  macro  and,  macro  nand,  and  macro 
xor.  Alpha  expansion  fo  the  old  form  did  not 
work. 


10  Mar  1987  J.  Harmon  compiled  taxi  program  with  no  errors. 


11  Mar  1987  J.  Harmon  updated  Makefile  for  installation  on 
ISI  cluster  workstations.  Updated  the  install 
routine  to  copy  the  new  executable  MacPitts 
with  Library  and  organelles. o  to  ISI1  and  ISI2. 


13  Mar  1987 


J.  Harmon  updated  all  sources  with  comments  IAW 
Brooks  Programming  In  Common  Lisp.  Added  make 
xref  to  the  Makefile  to  automatically  make  and 
print  a  cross  reference.  Added  a  Logfile  to 
the  compilation  steps  in  the  Makefile  to  save 
the  compilation  messages  in  one  log.  Updated 
make  clean  in  the  Makefile  to  remove  all  unused 
files  from  the  /usr/macpit  directory.  Compiled 
all  sources  without  errors  or  warnings.  In¬ 
stalled  new  version.  Generated  cross  refer¬ 
ence.  Cleaned  up  directory.  Made  all  source 
files  read  only.  This  established  the  initial 
baseline  of  MacPitts  on  the  ISI. 
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APPENDIX  B  SOFTWARE  CHANGE  PROPOSAL  SCP-2 


SOFTWARE  CHANGE/SOFTWARE  ENHANCEMENT  PROPOSAL 
Based  on  DOD-STD-1679A(NAVY)  DI-E-2117A 

1.  System/ Project  Name:  MACPITTS 

2.  Date  Prepared:  22  April  1987 

3.  SCP  Number:  2 

4.  Title  of  SCP/SEP:  Selectable  Technology  CIF  Output 

5.  Originator:  J.  Harmon 

6.  Component(s)  affected:  L5.1  frame. 1  prepass. 1 

Makefile 

7.  Description  of  Problem/Need  for  SCP/SEP: 

The  current  CIF  output  of  MacPitts  for  4  or  5 
micron  hybrid  nMOS  and  SCMOS  is  not  the  same  as  the 
CIF  used  by  the  Magic  and  cifp  programs.  The  only 
program  that  is  compatible  with  the  current  CIF  is 
the  cifplot  program  from  the  Berkeley  CAD  tools.  A 
MacPitts  CIF  layout  is  grossly  distorted  when  loaded 
into  Magic.  The  names  of  sub-modules  in  the 
MacPitts  CIF  are  not  recognized  by  Magic  and 
input/output  signal  labels  are  not  attached  to  the 
proper  layers.  Any  designs  with  both  nMOS  and  SCMOS 
layers  is  not  acceptable  to  Magic.  A  CIF  file  must 
be  able  to  be  loaded  into  Magic  to  be  extracted  for 
the  Crystal,  ESIM,  and  RSIM  programs.  The  cifp 
program  used  to  plot  CIF  on  the  color  plotter 
connected  to  the  ISI  workstations  does  not  accept 
the  format  of  the  MacPitts  CIF. 

8.  Description  of  Recommended  SCP/SEP: 

This  change  adds  new  command  line  options  to 
MacPitts  named  "magic",  "nmos",  "cmos",  "scmos", 
"hybrid",  "3u",  "2u",  and  "1.2u".  If  "magic"  is 
included  in  the  command  line,  MacPitts  will  produce 
a  CIF  file  that  is  compatible  with  Magic  and  cifp. 
The  "nmos",  "cmos",  and  "scmos"  command  line  options 
specify  that  the  CIF  output  contains  only  the  layers 
that  are  valid  for  that  technology.  The  "hybrid" 
command  line  option  specified  that  the  CIF  output 


contains  both  nMOS  and  SCMOS  layers.  This  CIF 
cannot  be  loaded  into  Magic  but  can  be  plotted  with 
the  cifplot  and  cifp  programs.  The  "3u" ,  H2u",  and 
"1 . 2u"  command  line  options  specify  minimum  feature 
sizes  of  3,  2,  and  1.2  microns,  respectively.  Each 
technology  has  a  default  minimum  feature  size  and  a 
list  of  valid  minimum  feature  sizes.  The  program 
will  not  accept  an  invalid  combination  of  minimum 
feature  size  and  technology.  A  new  technology  or 
minimum  feature  size  entry  on  the  command  line 
replaces  any  previous  entries  and  defaults.  The  CIF 
file  includes  names  of  sub-modules  that  are  used  by 
Magic  and  input/output  labels  that  are  connected  to 
the  proper  layers.  The  default  technology  is  nMOS 
and  the  default  CIF  format  is  compatible  with  Magic. 
Each  technology  has  a  default  minimum  feature  size. 

9.  Alternatives/Impact  if  not  Approved: 

A  conversion  program  may  be  written  to  convert 
from  MacPitts  CIF  to  Magic  CIF  and  filter  undesired 
layers.  The  program  may  also  be  required  to  modify 
the  minimum  feature  size.  If  MacPitts  CIF  cannot  be 
loaded  properly  into  Magic,  then  the  Magic  design 
rule  checker  and  the  Crystal,  ESIM,  and  RSIM 
simulators  cannot  be  used  on  MacPitts  layouts. 

10.  Baselines  Affected:  13  March  1987  Version  1.00  MacPitts 

11.  Documentation/Specifications  Affected: 

RVLSI-3,  An  Introduction  to  Macpitts.  J.R.  Southard 
10  February  1983 

RVLSI-5 ,  L5  User's  Guide.  K.W.  Crouch  7  March  1984 

12.  Other  Systems  or  Configuration  Items  Affected:  None. 


13.  Effect  of  SCP/SEP  on  System  Employment,  Integrated 

Logistics  Support  (ILS),  Training,  Effectiveness,  etc: 

This  SCP  would  increase  the  number  of  programs 
that  could  use  MacPitts  CIF.  This  would  increase 
the  employment  and  effectiveness  of  MacPitts.  There 
would  be  no  change  in  ILS.  Use  of  the  magic  command 
line  option  of  MacPitts  and  procedures  for  using 
MacPitts  layouts  in  Magic,  Crystal,  ESIM,  and  RSIM 
would  have  to  be  included  in  the  Silicon  Compiler 
Training  Syllabus. 


14.  Net  Effect  on  System  Resources  (e.g..  Processing  Time, 

Memory/Disk  Space) : 

This  change  adds  less  than  500  lines  of  changes 
and  additions  to  the  MacPitts  source  code,  including 
comments  and  separator  lines.  The  size  of  the 
compiled  program  is  not  significantly  increased. 

Run  time  memory  requirements  on  a  sample  design 
should  increase  by  10%  and  design  compile  time 
should  increase  by  10%  to  20%. 

15.  Developmental  Requirements:  4  man-weeks  for  recoding 

and  testing. 

16.  SCP/SEP  Effectivity  Point:  As  soon  as  possible 

17.  Date  Approval  Needed  By:  No  applicable  established 

schedule. 

18.  This  SCP/SEP  Must  be  Accomplished  Before/With/After: 

No  relationship  to  other  pending  modifications. 

19.  Supersedes  or  Replaces  SCP/SEP/STR: 

This  SCP  supersedes  SCP-1/ 

2  0 .  Approved  By : 

21.  Approval  Date: 

22.  Changes  Installed  By: 

23.  Installation  Date: 

Testing  Results: 

Several  designs,  including  incrementer.mac  and  taxi. mac, 
have  been  compiled  with  these  changes  and  successfully 
loaded  into  Magic  and  cifp.  The  design  are  not  distorted, 
the  sub-module  names  are  recognized  by  Magic,  and  the 
input/ output  labels  are  connected  to  the  proper  layers. 

A  run  without  the  magic  option  selected  produced  the 
same  CIF  output  as  the  baseline  program  without 
modifications  with  the  exception  of  the  system 
identification  comment  added  in  the  modifications. 

ROMO,  ROM1 ,  and  ROMnull  cells  with  SCMOS  layers  have 
been  generated  and  loaded  into  Magic. 


All  changes  listed  in  the  remainder  of  this  software  change 
proposal  are  a  combination  of  modified  original 
MacPitts  programs  and  new  programs. 

The  following  are  changes  to  L5.1: 

;;;?;?  »»»  Add  the  following  to  the  modification  history: 

;;;  8  Apr  1987  J.  Harmon  added  the  capability  to  output  CIF 

; ; ;  in  Magic  compatible  format  by  adding  a  new 

;;;  global  variable,  — L5-magic-flag,  an 

; ; ;  initialization  procedure  for  the  new 

;;;  variable,  and  new  functions  magic!  and 

; ; ;  magic?  to  change  and  query  the  value  of  the 

;;;  variable  respectively.  Added  conditional 

;;;  processing  to  the  cifout,  ci f out-external - 

;;;  names,  cif out-external -name,  cifout-def ine- 

;;;  symbol,  cifout-call-symbol ,  move-symbol, 

;;;  cifout-rect,  and  merge-cifout-files 

;;;  functions.  Upgraded  the  lambda-to- 

; ; ;  centimicron  function  to  convert  lambda 

;;;  measurements  to  scaled  Magic  measurements. 

•  •  • 

III 

; ; ;  14  Apr  1987  J  Harmon  added  new  global  variables  — L5- 
; ; ;  scale-factor-a  and  — L5-scale-factor-b  to  L5 

; ; ;  for  scaling  the  numbers  in  the  cifout 

;;;  section.  The  number  output  is  the  number  of 

; ; ;  centimicrons  times  — L5-scale-factor-b  and 

;;;  divided  by  — L5-scale-factor-a.  Added  new 

; ; ;  initialization  for  the  two  new  global 

;;;  variables.  Updated  lambda -to-centimicron  to 

;;;  use  the  new  scale  factors.  Added  new 

; ; ;  function  set-scale-factors  to  set  the  values 

; ? ;  of  the  scale  factors  and  scale-factor-a?  and 

; ; ;  scale- factor-b?  to  return  the  values  of  the 

;;;  scale  factors.  Updated  cifout-def ine  symbol 

;;;  to  use  the  new  scale  factors.  Updated 

; ; ;  allowed-layers  to  remove  SCMOS  layers  from 

;;;  the  nMOS  technology  and  add  the  SCMOS,  CMOS, 

;;;  and  hybrid  technologies.  Added  allowed- 

; ; ;  technologies?  to  test  for  a  valid 

; ; ;  technology,  default-minimum-feature-size  and 

; ; ;  allowed-feature-sizes  to  return  the  default 

; ; ;  and  valid  minimum  feature  sizes  for  the 

;;?  current  technology,  and  pad-glass-layer?  to 

; ; ;  return  the  layer  for  the  pad  holes  in  the 

;;;  over-glass  layer  in  the  current  technology. 

; ; ;  Added  convert-feature-size  to  convert  a 

;;;  minimum  feature  size  command  line  option  to 

?;?  a  lambda  spacing,  updated  rect,  box,  and 

;;;  mark  to  process  layers  correctly. 


16  Apr  1987  J  Hannon  changed  the  name  of  minimum- 
feature-size!  and  minimum-feature-size 
functions  tc  lambda-spacing!  and  lambda¬ 
spacing  ana  changed  the  name  of  the  global 
variable  — L5-minimum-feature-size  to  — L5- 
lambda-spacing  to  avoid  confusion.  The 
value  used  in  these  functions  and  variable 
is  for  the  lambda  spacing  and  not  the 
minimum  feature  size  that  is  twice  the 
lambda  spacing. 

16  Apr  1987  J  Harmon  added  defsymbols  for  common  SCMOS 
contacts . 


;;;;;»»  Replace  the  following  declaration  in  Headers 
section 

(declare 

; ;  8  Apr  87  J  Harmon  added  new  global  variable  — L5- 

; ;  magic-flag  to  be  used  to  select  magic  style 

;;  cif  output.  A  value  of  nil  or  ()  disables 

; ;  magic  cif  output  and  a  value  of  t  or  non-nil 

;;  value  enables  magic  cif  output. 

•  • 

/  t 

; ;  14  Apr  87  J  Harmon  added  new  global  variables  — L5- 

; ;  scale-factor-a  and  — L5-scale-factor-b  to 

;;  specify  the  scaling  used  in  CIF  output. 

•  • 
t  r 

; ;  16  Apr  87  J  Harmon  changed  name  of  — L5-minimum- 
; ;  feature-size  to  — L5-lambda-spacing  for 

;;  clarity.  The  minimum  feature  size  is  two 

; ;  times  the  lambda  spacing. 

(special  — L5-magic-flag 

— L5-scale-factor-a 
— L5-scale-factor-b 
— L5-symbol-port 
— L5-symbol-f ile 
— L5-symbol-list 
— L5-symbol -number 
— L5-technology 

;;jh  changed  name  of  — L5-minimum-feature-size  to 
;;  — L5-lambda-spacing  for  clarity.  The 

; ;  minimum  feature  size  is  two  times  the  lambda 
;;  spacing. 

— L5-lambda-spacing 

attributes 

dx 

dy 

name 


item-tree 
path 
symbol 
symbol-id) ) 

;;;;;»>Add  or  replace  the  following  setqs  to  the  Global 
; ; ; ;  ;»>Variables  part  of  the  Definitions  section. 

(setq  — L5-magic-flag  ()) 

; ;  8  Apr  87  J  Harmon  added  initialization  for  the  new  — 

;;  L5-magic-flag  variable.  The  initial  setting 

; ;  is  with  magic  cif  output  disabled. 

(setq  — L5-scale-factor-a  1) 

; ;  14  Apr  87  J  Harmon  added  initialization  for  the  new 
;;  — L5-scale-factor-a  variable.  The  initial 

;;  setting  is  1. 

(setq  — L5-scale-factor-b  1) 

; ;  14  Apr  87  J  Harmon  added  initialization  for  the  new 
;;  — L5-scale-factor-b  variable.  The  initial 

;;  setting  is  1. 

(setq  — L5-lambda-spacing  200) 

; ;  16  Apr  87  J  Harmon  changed  name  of  — L5-minimum-feature- 
;;  size  to  — L5-lambda-spacing  for  clarity.  The 

; ;  minimum  feature  size  is  two  times  the  lambda 

; ;  spacing.  Also  made  the  default  lambda  spacing 

;;  200  centimicrons. 

;;;;;»>Add  or  replace  the  following  functions  to  the 
; ; ; ;  ;»>Changeable  common  definitions  part  of  the  Common 
; ; ; ;  ;»>functions  section 

(def  lambda  spacing! 

;;  16  Apr  87  J  Harmon  renamed  minimum-feature-size! 

; ;  function  to  lambda-spacing!  and  replaced  all 

;;  references  to  minimum  feature  size  to  lambda 

;;  spacing  to  avoid  confusion.  The  actual 

; ;  value  used  in  the  program  is  the  lambda 

; ;  spacing  and  not  the  minimum  feature  size 

;;  that  is  two  times  the  lambda  spacing. 

(lambda  (lambda-spacing) 

(setq  — L5-lambda-spacing  lambda-spacing))) 

(def  lambda  spacing 

; ;  16  Apr  87  J  Harmon  renamed  minimum-feature-size 
;;  function  to  lambda-spacing  and  replaced  all 

; ;  references  to  minimum  feature  size  to  lambda 

;;  spacing  to  avoid  confusion.  The  actual 

; ;  value  used  in  the  program  is  the  lambda 


; ;  spacing  and  not  the  minimum  feature  size 

;;  that  is  two  times  the  lambda  spacing. 

(lambda  () 

— L5-lambda-spacing) ) 

(def  magic! 

;;  8  Apr  87  J  Harmon  added  the  magic!  function  that  sets 

; ;  the  value  of  the  L5  global  variable  — L5- 

;;  magic-flag  to  the  argument  of  the  magic! 

;;  function.  This  allows  separately  compiled 

; ;  procedures  to  set  the  flag  without  direct 

;;  access  to  the  variable. 

(lambda  (magic-flag) 

(setq  — L5-magic-flag  magic-flag))) 

(def  magic? 

; ;  8  Apr  87  J  Harmon  added  the  magic?  function  that  reads 

; ;  the  value  of  the  L5  global  variable  — L5- 

; ;  magic-flag  and  returns  it  as  the  value  of  the 

;;  magic?  function.  This  allows  separately 

; ;  compiled  procedures  to  read  the  flag  without 

;;  direct  access  to  the  variable. 

(lambda  () 

— L5-magic-flag) ) 

(def  set-scale-factors 

; ;  14  Apr  87  J  Harmon  added  set-scale-factors  function  that 
; ;  sets  the  values  of  the  two  new  variables  — L5- 

; ?  scale-factor-a  and  — L5-scale-factor-b  to  the 

;;  values  passed  to  the  function. 

(lambda  (scale-a  scale-b) 

(setq  — L5-scale-factor-a  scale-a) 

(setq  — L5-scale-factor-b  scale-b))) 

(def  scale-factor-a 

; ;  14  Apr  87  J  Harmon  added  a  new  scale-factor-a  function 
; ;  that  returns  the  value  of  the  new  variable  — 

; ;  L5-scale-factor-a 

(lambda  () 

— L5-scale-factor-a) ) 

(def  scale-factor-b 

; ;  14  Apr  87  J  Harmon  added  a  new  scale-factor-b  function 
; ;  that  returns  the  value  of  the  new  variable  — 

; ;  L5-scale-factor-b 

( lambda  ( ) 

— L5-scale-factor-b) ) 

(def  allowed-technologies 

;;  14  Apr  87  J  Harmon  added  allowed-technologies  function 
;;  to  L5 .  This  function  returns  a  list  of 


allowed  technologies. 


(lambda  () 

1 (nmos  cmos  scmos  hybrid) ) ) 

(def  allowed-layers 

;;  23  Jan  87  E.  Malagon  added  allowed  layers.  Allows 
;;  changing  from  default  nmos  to  cmos,  scmos. 

; ;  Adds  hybrid  nmos  technology  that  has  both  nmos 

; ;  and  scmos  layers . 

; ;  14  Apr  87  J  Harmon  added  hybrid  technology  and  reduced 
;;  nmos  layers  to  actual  nmos  layers. 

(lambda  () 

(cond 

((eq  'nmos  (technology))  * (ND  NP  NM  NI  NC  NG  NB  NX  XP) ) 
((eq  'hybrid  (technology))  • (ND  NP  NM  NI  Nc  NG  NB  NX  XP 
CPG  CAA  CMF  CMS  CSN  CSP  CCP  CCA  CVA  COG  CWP  CWN) ) 
((eq  'cmos  (technology))  '(CD  CP  CM  CM2  CS  CC  CG  CW  NX 
XP)) 

((eq  'scmos  (technology))  * (CPG  CAA  CMF  CMS  CSN  CSP  CCP 
CCP  CVA  COG  CWP  CWN) ) 

(t  (L5-err 

' | That  technology  is  not  recognized  by  L5 j ) ) ) ) ) 

(def  default-minimum-feature-size 
; ;  14  Apr  87  J  Harmon  added  new  function  default-minimum- 
; ;  feature-size  that  returns  a  default  minimum 

;;  feature  size  for  the  current  L5  technology, 

(lambda  () 

(cond 

((eq  'nmos  (technology))  '4u) 

( (eq  'hybrid  (technology))  '3u) 

( (eq  'cmos  (technology))  '3u) 

( (eq  'scmos  (technology))  '3u) 

(t  (L5-err 

' | That  technology  is  not  recognized  by  L5 | ) ) ) ) ) 

(def  allowed-minimum-feature-sizes 
; ;  14  Apr  87  J  Harmon  added  a  new  function  allowed-minimum- 
; ;  feature-sizes  that  returns  a  list  of  the 

; ;  allowed  minimum  feature  sizes  for  the  current 

;;  technology. 

(lambda  () 

(cond 

((eq  'nmos  (technology))  ' (4u  5u) ) 

((eq  'hybrid  (technology))  '(1.2u  2u  3u  4u  5u) ) 

((eq  'cmos  (technology))  ' (4u  5u)) 

( (eq  'scmos  (technology))  '(1.2u  2u  3u) ) 

(t  (L5-err 

'| That  minimum  feature  size  is  not  recognized  by  L5 | ) ) ) ) ) 


(def  convert-feature-size 

; ;  14  Apr  87  J  Hannon  added  a  new  function  convert- feature- 
; ;  size  that  accepts  a  minimum-feature-size  in 

;;  option-list  format  and  returns  the  lambda 

;;  spacing  in  centimicrons. 

(lambda  (min-size) 

(cond 

((eq  ' 5u  min-size)  250) 

( (eq  • 4u  min-size)  200) 

( (eq  ' 3u  min-size)  150) 

( (eq  ' 2u  min-size)  100) 

( (eq  ' 1 . 2u  min-size)  60) 

(t  (L5-err  '(That  minimum  feature  size  is  not  recognized 
by  L5|))))) 

(def  pad-glass-layer 

; ;  14  Apr  87  J  Harmon  added  function  pad-glass-layer  that 
; ;  returns  the  glass  layer  associated  with  pads 

;;  in  the  current  technology. 

(lambda  () 

(cond 

((eq  'nmos  (technology))  'NG) 

( (eq  'hybrid  (technology))  'NG) 

( (eq  'cmos  (technology))  *CG) 

( (eq  'scmos  (technology))  ’COG) 

(t  (L5-err 

' | That  technology  is  not  recognized  by  L5 | ) ) ) ) ) 
;;;»>  Replace  the  following  in  the  Item  Creation  section: 
(def  rect 

; ;  14  Apr  87  J  Harmon  removed  the  test  for  a  valid  layer 
; ?  from  the  rect  function.  This  allows  the 

; ;  cifout-rect  function  to  determine  if  a 

;;  rectangle  should  be  put  into  the  output, 

(lambda  (layer  Xmin  Ymin  Xmax  Ymax) 

(cond 

;;  jh  removed  test  for  valid  layer  from  rect  function. 

; ;  This  allows  the  cifout-rect  function  to  determine 
;;  if  a  rectangle  should  be  put  into  the  output. 

( (greaterp  Xmin  Xmax)  (L5-err 

'| Xmin  should  be  less  than  or  equal  to  Xmax|)) 
( (greaterp  Ymin  Ymax)  (L5-err 

•| Ymin  should  be  less  than  or  equal  to  Ymax|)) 
(t 

(make- item 
Xmin 
Ymin 
Xmax 
Ymax 
0 


0 

(make-rect-tree  layer  Xmin  Ymin  Xmax  Ymax  )))))) 

(def  box 

;;  14  Apr  87  J  Harmon  removed  the  test  for  a  valid  layer 
;;  from  the  box  function.  This  allows  the 

; ;  cifout-rect  function  to  determine  if  a 

; ;  rectangle  should  be  put  into  the  output . 

(lambda  (layer  length  width  xcenter  ycenter) 

(cond 

?;  jh  removed  test  for  valid  layer  from  box  function. 

; ;  This  allows  the  cifout-rect  function  to  determine 
;;  if  a  rectangle  should  be  put  into  the  output, 
((lessp  length  0)  (L5-err  '{illegal  box  length|)) 
((lessp  width  0)  (L5-err  ' {Illegal  box  widthj)) 

(t 

(let  ((Xmin  (diff  xcenter  (quotient  length  2.0))) 

(Ymin  (diff  ycenter  (quotient  width  2.0))) 

(Xmax  (plus  xcenter  (quotient  length  2.0))) 

(Ymax  (plus  ycenter  (quotient  width  2.0)))) 
(make-item 
Xmin 
Ymin 
Xmax 
Ymax 
0 
0 

(make-rect-tree  layer  Xmin  Ymin  Xmax  Ymax) )))))) 

(def  mark 

; ;  14  Apr  87  J  Harmon  removed  the  test  for  a  valid  layer 
;;  from  the  mark  function.  This  allows  the 

; ;  cifout-rect  function  to  determine  if  a 

;;  rectangle  should  be  put  into  the  output, 

(lambda  (name  x  y  layer  attributes) 

(cond 

((not  (number?  x) ) 

(L5-err  1 | Point  x  coordinate  must  be  a  number|)) 

( (not  (number?  y) ) 

(L5-err  ' | Point  y  coordinate  must  be  a  number|)) 

;;  jh  removed  test  for  valid  layer  from  mark  function. 

; ;  This  allows  the  cifout-rect  function  to  determine 
;;  if  a  rectangle  should  be  put  into  the  output, 
((not  (list?  attributes)) 

(L5-err  '| Point  attributes  must  be  in  a  list|)) 

(t 

(make-item 


(make-points  (make-point  (list  name)  x  y  layer 

attributes) ) 

0 

(make-null-tree) ) ) ) ) ) 

; ; ; ;  ;»»>Replace  the  following  functions  in  the  Item  cifout 
; ; ; ;  ;»»>section 

(def  cifout 

; ;  8  Apr  87  J  Harmon  added  Magic  compatible  cifout 

;;  operations. 

; ;  16  Apr  87  J  Harmon  replaced  the  function  minimum- 
; ;  feature-size  with  the  new  function  name 

;;  lambda-spacing  in  cifout  to  avoid  confusion. 

; ;  the  value  used  is  the  lambda  spacing  and  not 

; ;  the  minimum  feature  size  that  is  twice  the 

;;  lambda  spacing. 

(lambda  (item  file  title) 

(cond 

((null  item)  (L5-err  1 | Cannot  cifout  null  item|)) 

(t  (let  ( (cifout-file  (concat  file  '.cif)) 

(cifout-portl 

(outfile  (concat  (scratch-directory)  '/  file 

* -cif  1))) 

(cifout-f ilel  (concat  (scratch-directory)  '/ 

file  '.cif  1)) 

(cifout-port2 

(outfile  (concat  (scratch-directory)  '/  file 

• .cif  2) ) ) 

(cifout-f ile2  (concat  (scratch-directory)  '/ 

file  » .cif  2) ) ) 

(terpri  (L5-symbol-port) ) 

(patom  "(Title  :  "  cifout-portl) 

(patom  title  cifout-portl) 

(patom  ");"  cifout-portl) 

(terpri  cifout-portl) 

(patom  "(U.S.  Naval  Postgraduate  School);" 

cifout-portl) 

(terpri  cifout-portl) 

; ;  jh  added  system  identification  comment  to  the  CIF 
; ;  header. 

(patom  " ( ECE  Department  ISI  System);"  cifout-portl) 
(terpri  cifout-portl) 

(patom  "(lambda  is  "  cifout-portl) 

(patom  (lambda-spacing)  cifout-portl) 

(patom  "  centimicrons) ; "  cifout-portl) 

(terpri  cifout-portl) 

;;  jh  added  symbol  1  with  a  scaling  factor  of  50  to 

;;  the  CIF  header.  Also  added  CIF  User  Extension 

; ;  9  with  the  title  to  make  the  name  of  the  new 

;;  symbol  1  be  the  title  of  the  design.  Also 


;;  added  processing  for  the  magic  option. 

(cond  ((magic?)  (patom  "DS  1  "  cifout-portl) 

; ;  14  Apr  87  jh  added  variable  scale 
; ;  factors 

(patom  (scale-factor-a)  cifout-portl) 
(patom  "  "  cifout-portl) 

(patom  (scale-factor-b)  cifout-portl) 
(patom  cifout-portl) 

(terpri  cifout-portl) 

(patom  "9  "  cifout-portl) 

(patom  title  cifout-portl) 

(patom  ";M  cifout-portl) 

(terpri  cifout-portl))) 

(cif out-external-names 

(find-attributes  item  '(external))  cifout-portl) 
;;  jh  deleted  extra  line  for  magic  CIF  output 
(cond  ( (not (magic?) )  (terpri  cifout-portl))) 

; ;  jh  added  processing  to  determine  which  file  gets 
; ;  the  tree  output 

(cif out-tree-walker  (item-tree  item)  () 

(cond  ((magic?)  cifout-portl) 

(t  cifout-port2) ) ) 

;;  jh  added  end  of  symbol  1  for  magic. 

(cond  ((magic?)  (patom  "DF;"  cifout-portl) 

(terpri  cifout-portl) ) 

(t  (patom  "End"  cifout-port2) ) ) 

;;  jh  added  processing  to  determine  which  file  gets 
;;  end  of  line. 

(terpri  (cond  ((magic?)  cifout-portl) 

(t  cifout-port2) ) ) 

; ;  jh  added  call  to  symbol  1  and  end  for  magic  CIF 
; ;  output 

(cond  ((magic?)  (patom  "C  1;"  cifout-port2) 

(terpri  cifout-port2) 

(patom  "End"  cifout-port2) 

(terpri  cifout-port2) ) ) 
(merge-cifout-f iles  cifout-file  cifout-filel 

cifout-file2) 

(close  cifout-portl) 

(close  cifout-port2) ) ) ) ) ) 

(def  cifout-external-naraes 

;;  24  Jan  87  E.  Malagon  added  the  char  't'  to  the  call  to 
; ;  cifout-external-name  in  cifout-external-names 

;;  to  initiate  non-MIT  option.  This  allows 

;;  points  to  be  plotted  with  their  labels.  '94' 

;;  extension  is  more  conventional  than  the  'O' 

; ;  extension. 

;;  8  Apr  87  J.  Harmon  removed  extra  line  for  Magic  CIF 

(lambda  (points  cifout-port) 

(cond 


;;  jh  removed  extra  line  for  magic  CIF  option 
((null  points)  (cond  ( (not (magic?) ) 

(terpri  cifout-port) ) ) ) 
(t 

(cifout-external-name  (car  points)  cifout-port  t) 
(cifout-external-names  (cdr  points)  cifout-port) ) ) ) ) 

(def  cifout-external-name 

7  7  24  Jan  87  E.  Mai agon  added  non-MIT  option  to  cifout- 
7 ?  external -name 

7  7  25  Mar  87  J.  Harmon  changed  name  of  VDD  to  Vdd  for 
; ?  proper  simulator  input 

7  7  25  Mar  87  J.  Harmon  added  exclamation  point  to  end  of 
;;  external  names  for  proper  simulator  input. 

7  7  8  Apr  87  J.  Harmon  added  rectangles  of  metal  and  pad 

; ;  for  proper  binding  of  labels  to  materials  in 

?;  Magic. 

; ?  14  Apr  87  J  Harmon  added  processing  to  make  cifout- 
;;  external-name  technology  independent,  it  only 

;;  outputs  an  external  name  if  it  is  for  a  valid 

;;  layer  in  the  current  technology.  The  layer 

; ;  for  the  hole  in  the  over-glass  is  determined 

7  7  by  the  pad-glass-layer  function.  The  layer 

7  7  used  is  based  on  the  current  technology, 

(lambda  (point  cifout-port  fioptional  non-MIT) 

(let  ((name  (capitalize  (atomize-external-name 

(point-name  point) ) ) ) ) 

; 7  jh  added  a  box  of  metal  under  each  external  name  so 
? ;  that  magic  leaves  the  label  for  the  name  connected 
; ;  to  metal  rather  than  move  it  to  space  when  the  CIF 
77  file  is  loaded  into  magic. 

77  jh  added  test  for  a  valid  layer 

(cond  ((member  (point-layer  point)  (allowed-layers) ) 

(cond  ((magic?)  (patom  "L  "  cifout-port) 

(patom  (point-layer  point)  cifout-port) 
(patom  B  L  "  cifout-port) 

(patom  (lambda-to-centimicron  4) 

cifout-port) 

(patom  "  W  "  cifout-port) 

(patom  (lambda-to-centimicron  4) 

cifout-port) 

(patom  "  C  "  cifout-port) 

(patom  (lambda-to-centimicron 

(point-x  point) )  cifout-port) 
(patom  ",  "  cifout-port) 

(patom  (lambda-to-centimicron 

(point-y  point) )  cifout-port) 
(patom  " y”  cifout-port) 

(terpri  cifout-port) 

(patom  ”L  "  cifout-port) 

77  jh  replaced  fixed  glass  layer  with  a 


; ;  call  to  the  function  that  returns  the 
; ;  glass  layer  for  the  current 

;;  technology. 

(patom  (pad-glass-layer)  cifout-port) 

(patom  " ;  B  L  "  cifout-port) 

(patom  (lambda-to-centimicron  4) 

cifout-port) 

(patom  "  W  H  cifout-port) 

(patom  (lambda-to-centimicron  4) 

cifout-port) 

(patom  "  C  "  cifout-port) 

(patom  (lambda-to-centimicron 

(point-x  point) )  cifout-port) 
(patom  ",  "  cifout-port) 

(patom  (lambda-to-centimicron 

(point-y  point) )  cifout-port) 
(patom  " cifout-port) 

(terpri  cifout-port) ) ) 

(cond  (non-MIT  (patom  "94  "  cifout-port) 

;;  jh  Changed  name  of  VDD  to  Vdd  for  proper 
;;  simulator  input. 

(cond  ((and  (magic?)  (equal  name  'VDD)) 
(patom  "Vdd"  cifout-port) 

(t  (patom  name  cifout-port) ) ) 

; ;  jh  Added  exclamation  point  to  end  of 
; ;  external  names  for  proper  simulator 

; ;  input . 

(cond  ((magic?)  (patom  cifout-port))) 
(patom  "  "  cifout-port) 

(patom  (lambda-to-centimicron 

(point-x  point) )  cifout-port) 
(patom  "  "  cifout-port) 

(patom  (lambda-to-centimicron 

(point-y  point) )  cifout-port) 
(patom  "  "  cifout-port) 

(patom  (point-layer  point)  cifout-port) 
(patom  cifout-port) 

(terpri  cifout-port)) 

(t  (patom  "0  "  cifout-port) 

(patom  (lambda-to-centimicron 

(point-x  point) )  cifout-port) 
(patom  "  "  cifout-port) 

(patom  (lambda-to-centimicron 

(point-y  point) )  cifout-port) 
(patom  "  "  cifout-port) 

(patom  (point-layer  point)  cifout-port) 
(patom  "  N  "  cifout-port) 

(patom  name  cifout-port) 

(patom  cifout-port) 

(terpri  cifout-port) ))))))) 
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(def  cif out-def ine-symbol 

; ;  8  Apr  87  J  Hannon  added  Magic  compatible  define  symbol 

; ;  output . 

; ;  14  Apr  87  J  Harmon  added  scale  factor  output  to  cifout- 

; ;  def ine-symbol 

(lambda  (item  function-name  cif out -port) 

(patom  MDS  "  cifout-port) 

; ;  jh  Added  1  to  the  structure  number  for  magic  CIF 
;;  output.  Structure  number  1  is  the  whole  design. 

;;  added  scale  factor  for  magic. 

(cond  ((magic?) 

(patom  (1+  (length  (L5-symbol-list) ) )  cifout-port) 
(patom  H  "  cifout-port) 

; ;  jh  added  the  scale  factor  printing  from  the  new 
;;  scale-factor-a  and  scale-factor-b  functions, 
(patom  (scale-factor-a)  cifout-port) 

(patom  "  "  cifout-port) 

(patom  (scale-factor-b)  cifout-port) 

(t  (patom  (length  (L5-symbol-list) )  cifout-port))) 
(patom  cifout-port) 

(terpri  cifout-port) 

; ;  jh  Added  function  9  for  magic  CIF  output  to  name  a 
;;  structure  with  the  function  name. 

(cond  ((magic?) 

(patom  "9  "  cifout-port) 

(patom  function-name  cifout-port) 

(patom  " cifout-port) 

(t 

(patom  "(name:  ”  cifout-port) 

(patom  function-name  cifout-port) 

(patom  ");"  cifout-port))) 

(terpri  cifout-port) 

(patom  "(bounding  box:  "  cifout-port) 

(patom  (left  item)  cifout-port) 

(patom  " , ”  cifout-port) 

(patom  (bottom  item)  cifout-port) 

(patom  " cifout-port) 

(patom  (right  item)  cifout-port) 

(patom  " cifout-port) 

(patom  (top  item)  cifout-port) 

(patom  " ) cifout-port) 

(terpri  cifout-port) 

(patom  "DF;"  cifout-port) 

(terpri  cifout-port) ) ) 

(def  cifout-call-symbol 

; ;  8  Apr  87  J  Harmon  added  1  to  symbol  numbers  for  Magic 

; ;  CIF  output 

(lambda  (symbol -call -tree  stack  cifout-port) 

(cond 

(t 
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(patom  "C  "  cif out-port) 

; ;  jh  added  1  to  symbol  numbers  for  magic  CIF  since 
; ;  symbol  1  is  the  whole  design 
(cond  ((magic?) 

(patom 

(1+  (symbol-call-tree-name  symbol-call-tree)) 
cifout-port) ) 

(t 

(patom 

(symbol-call-tree-name  symbol-call-tree) 
cifout-port) ) ) 

(patom  "  "  cifout-port) 

(cifout-called-symbol -operation-handler  stack 
cifout-port) 

(patom  " cifout-port) 

(terpri  cifout-port) ) ) ) ) 

(def  cifout-rect 

;;  14  Apr  87  J  Harmon  added  a  test  for  valid  layers  to 
;;  cifout-rect. 

(lambda  (rect-tree  cifout-port) 

(cond 

((or  (=0  (rect-width  rect-tree)) 

(=0  (rect-length  rect-tree))) 

0) 

; ;  jh  added  a  test  for  valid  layer  to  cifout-rect 
((member  (rect-tree-layer  rect-tree)  (allowed-layers) ) 
(let  ((center  (rect-center  rect-tree))) 

(patom  "L  "  cifout-port) 

(patom  (rect-tree-layer  rect-tree)  cifout-port) 

(patom  " ;  B  L  "  cifout-port) 

(patom  (lambda-to-centimicron  (rect-length  rect-tree)) 
cifout-port) 

(patom  "  W  "  cifout-port) 

(patom  (lambda-to-centimicron  (rect-width  rect-tree)) 
cifout-port) 

(patom  "  C  "  cifout-port) 

(patom  (lambda-to-centimicron  (car  center)) 
cifout-port) 

(patom  ",  "  cifout-port) 

(patom  (lambda-to-centimicron  (cadr  center)) 
cifout-port) 

(patom  " cifout-port) 

(terpri  cifout-port)))))) 

(def  lambda-to-centimicron 

; ;  14  Apr  87  J  Harmon  added  processing  of  scale  factors  in 
;;  the  function  lambda-to-centimicron. 

; ;  16  Apr  87  J  Harmon  replaced  minimum-feature-size  with 
; ;  lambda-spacing  in  lambda-to-centimicron  to 

;;  avoid  confusion.  The  value  used  is  the  lambda 
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spacing  and  not  the  minimum  feature  size  that 
, ,  is  twice  the  lambda  spacing. 

(lambda  (number) 

(fix  (plus  .5  (quotient 

(times  (scale-factor-b) 

(times  (lambda-spacing)  number) ) 
(scale-factor-a) ) ) ) ) ) 

;;;;;>»»Add  the  following  heading,  note,  and  functions  to 
;;;;;»>»the  Basic  Items  section: 

; ; ;  ***  SCMOS  Contacts  *** 

;;;  Note:  The  substrate  contacts  called  nsubstratencontact , 
77  7  nncontact,  nsc,  nnc,  psubstratepcontact , 

77  7  ppcontact,  psc,  and  ppc  are  not  included  as 

; ; ?  default  structures  since  they  do  not  act  properly 

77?  in  Magic  as  separate  symbols.  They  produce 

; ; ;  inconsistencies  between  layers  in  different 

7 ; ;  cells.  These  contacts  must  be  built  inside  each 

777  layout. 


i 

i 

i 


I 

\ 


i 


i 

i 

i 


i 

i 


i 
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(defsymbol  polycontact  ()  i 

7  7  16  Apr  87  J  Harmon  added  a  defsymbol  for  a  SCMOS  ] 

77  polycontact.  ; 

(merge  « 

(rect  ' CPG  0-440)  \ 

(rect  ' CMF  0-440)  1 

(rect  'CCP  1-33-1)))  ; 

t 

(def  pcontact  « 

7  7  16  Apr  87  J  Harmon  added  a  function  pcontact  that 
7 7  returns  a  polycontact  symbol 

(lambda  () 

(polycontact)))  j 

i 

(def  pc  * 

7 7  16  Apr  87  J  Harmon  added  a  function  pc  that  returns  ! 

7  7  a  polycontact  symbol  \ 

(lambda  ()  ( 

(polycontact))) 

(defsymbol  ndcontact  ()  I 

; 7  16  Apr  87  J  Harmon  added  a  defsymbol  for  a  SCMOS  J 

?7  ndcontact.  > 

(merge  1 

(rect  'CAA  0-440)  ; 

(rect  'CMF  0-440)  f 

(rect  'CCA  1-33  -1)  l 

(rect  'CWP  -5-995)))  j 


1 

) 


I  >■>«.«<<>  «.» >4>  -  rt  ini’ll*.  4 


(def  ndc 

; ;  16  Apr  87  J  Hannon  added  a  function  ndc  that  returns 
; ;  a  ndcontact  symbol 

(lambda  () 

(ndcontact) ) ) 


(defsymbol  pdcontact  () 

; ;  16  Apr  87  J  Harmon  added  a  defsymbol  for  a  SCMOS 
; ;  pdcontact . 

(merge 

(rect  'CAA  0-440) 

(rect  ' CMF  0-440) 

(rect  'CCA  1-33  -1) 

(rect  'CSP  -2  -6  6  2) ) ) 


(def  pdc 

; ;  16  Apr  87  J  Harmon  added  a  function  pdc  that  returns 
; ;  a  pdcontact  symbol 

(lambda  () 

(pdcontact) ) ) 


(defsymbol  m2contact  () 

; ;  16  Apr  87  J  Harmon  added  a  defsymbol  for  a  SCMOS 
;;  m2 contact. 

(merge 

(rect  'CMF  0  -4  4  0) 

(rect  'CMS  0  -4  4  0) 

(rect  ' CVA  1  -3  3  -1))) 


(def  m2c 

; ;  16  Apr  87  J  Harmon  added  a  function  m2c  that  returns 
; ;  a  m2 contact  symbol 

( lambda  ( ) 

(m2 contact) ) ) 


(def  via 

; ;  16  Apr  87  J  Harmon  added  a  function  via  that  returns 
; ;  a  m2contact  symbol 

(lambda  () 

(m2contact) ) ) 


(def  v 

; ;  16  Apr  87  J  Harmon  added  a  function  v  that  returns 
; ;  a  m2 contact  symbol 

(lambda  () 

(m2 contact) ) ) 


Make  the  following  changes  to  prepass. 1: 


;;;;;»»>  Add  the  following  to  the  modification  history: 

; ; ;  8  Apr  87  J  Harmon  added  the  capability  to  output  CIF  in 

; ; ;  Magic  compatible  format  by  adding  a  new 

;;;  command  line  option  "magic".  Added  processing 

; ; ;  for  the  new  option  to  the  macpitts-compiler 

?;;  and  process-option  functions. 

; ; ;  16  Apr  87  J  Harmon  added  processing  to  macpitts-compiler 
;;;  to  accommodate  technologies  specified  on  the 

; ; ;  command  line  and  add  additional  minimum 

;;;  feature  sizes.  Added  new  functions  process- 

;;;  command-line-options,  process-technology- 

;;;  option,  process-minimum-feature-size,  and 

; ; ;  process-magic-option  to  support  technology 

;;;  selection.  Upgraded  option  processing  to  have 

; ; ;  a  new  technology  selection  replace  all  current 

; ; ;  technology  selections  and  for  a  new  minimum 

; ; ;  feature  size  selection  to  replace  all  current 

;;;  minimum  feature  size  selections,  included  a 

;;;  default  technology,  and  default  minimum 

;;;  feature  sizes  for  each  technology.  Included 

;;;  checking  for  valid  technology/minimum  feature 

;;;  size  combinations.  Included  processing  to 

;;;  establish  scale  factors  for  CIF  output. 

?;?;;»>  add  or  replace  the  following  functions  in 
; ; ; ; ;  >»  prepass .  1 : 

(def  macpitts-compiler 

; ;  This  function  if  the  executive  program  for  the  macpitts 
; ;  compiler.  It  includes  command  line  option  processing 
;;  and  calls  all  programs  for  loading  the  library  file, 

;;  producing  object  file  output,  producing  CIF  output,  and 

;;  for  functionally  simulating  the  design  specification. 

•  • 
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; ;  8  Apr  87  J  Harmon  added  processing  in  macpitts-compiler 

;;  to  process  the  magic  command  line  option.  The 

; ;  processing  includes  setting  the  new  magic  flag 

; ;  in  L5  to  true  and  setting  the  minimum-feature- 

;;  size  to  200.  This  will  be  used  with  a 

;;  reduction  of  50  used  in  magic.  The  reduction 

; ;  factor  is  the  scaling  in  the  DS  lines  for  the 

; ;  CIF  that  has  a=100  and  b=2  meaning  that  the 

;;  reduction  factor  =  a/b  is  50.  This  is 

;;  multiplied  times  all  values  in  the  CIF  to  get 

;;  the  actual  value  in  centimicrons. 

;;  16  Apr  87  J  Harmon  added  processing  for  scmos,  cmos,  and 
; ;  hybrid  technologies  and  different  minimum 

;;  feature  sizes  to  macpitts-compiler.  Included 

; ;  calls  to  new  functions  to  process-command- 

;;  line-options,  process-technology-option, 


t  f 


process-minimum-feature-size,  and  process- 
magic-option. 

(lambda  (operands) 

(prog  (file-name  file  object  obj  item) 

(setq  initial-ptime  (ptime)) 

(setq  initial-gccount  \$gccount\$) 

(cond  ((or  (not  (list?  operands)) 

(null  operands) 

(not  (atom?  (car  operands)))) 

(patom  "usage:  (macpitts  <filename>  [<options>] ) ") 
(terpr) 

(return  ()))) 

(setq  file-name  (car  operands) ) 

; ;  jh  replaced  old  process-option  function  with  new 
;;  process-command-line-options  function.  The  new 

; ;  function  updates  the  option  list  with  the  options 
;;  specified  on  the  command  line, 

(process-command-line-options  (cdr  operands)) 

(statistic  (concat  "for  project  "  file-name)) 

(statistic  (concat  "options:  " 

(slash  (explode  option-list) 

II  II 

(function  concat)))) 

; ;  jh  added  new  function  to  process  the  technology 
;;  option.  This  function  finds  a  technology  in  the 
;;  option-list  and  sets  the  L5  technology.  If  there 
;;  is  no  technology  in  the  option-list,  the  default 
;;  nmos  technology  is  used. 

(process-technology-option) 

; ;  jh  added  new  function  to  process  the  minimum  feature 
;?  size  option.  This  function  finds  a  minimum  feature 

;;  size  in  the  option-list  and  sets  the  L5  minimum 

;;  feature  size.  If  there  is  no  minimum  feature  size 

;;  in  the  option-list,  a  default  minimum  feature  size 

; ;  is  used. 

(process-minimum-feature-size) 

;;  jh  added  a  new  function  to  process  the  magic  option. 

; ;  This  function  sets  or  clears  the  magic  flag  and 

;;  sets  the  scale  factors  for  magic  output, 

(process-magic-option) 

(cond  ((member?  'int  option-list) 

(cond  ((null  (catch  (interpret  file-name)  note)) 
(return  ()))))) 

(cond  ((or  (member?  'obj  option-list) 

(member?  'cif  option-list)) 

(setq  object  (get-object  file-name)) 

(t  (return  t) ) ) 

(cond  ((null  object)  (return  ()))) 

(statistic  (concat  "Data-path  has  " 

(length  (object-data-path  object)) 

»  Units")) 


(cond  ((member?  'obj  option-list) 

(herald  "Outputing  .obj  file") 

(setq  obj 

(make-object 

(purge-library  (object-definitions  object) 
(object-flags  object) 

(object-data-path  object) 

(object-control  object) 

(object-pins  object))) 

(setq  file  (outfile  (concat  file-name  ".obj"))) 
(pp-form  obj  file) 

(close  file) ) ) 

(cond  ((member?  'cif  option-list) 

(setq  item  (catch  (layout-object  object)  note)) 
(cond  ((null  item)  (return  ()))) 

(herald  "Outputing  .cif  file") 

(cifout  item  file-name  file-name) ) ) 

(statistic  (concat  "Memory  used  -  " 

(/  (memory)  1024)  "K")) 

(statistic  (concat  "Compilation  took  " 

(quotient  (-  (car  (ptime) ) 

(car  initial-ptime) ) 
3600.0) 

"  CPU  minutes")) 

(statistic  (concat  "Garbage  collection  took  " 

(quotient  (-  (cadr  (ptime)) 

(cadr  initial-ptime) ) 
3600.0) 

»  CPU  minutes")) 

(statistic  (concat  "For  a  total  of  " 

(-  \$gccount\$  initial-gccount) 

"  garbage  collections")) 

(return  t) ) ) ) 

(def  process-command-line-options 
; ;  8  Apr  87  J  Harmon  added  processing  to  process-option  to 

; ;  remove  options  with  a  no  prefix  from  the 

;;  option-list  if  the  option  without  the  no 

;;  prefix  is  specified  on  the  command  line. 

; ;  13  Apr  87  J  Harmon  moved  all  command  line  option 
; ;  processing  to  this  new  process-command-1 ine- 

;;  options  function. 

(lambda  (options) 

(do  ((input-list  options  (cdr  input-list))) 

((atom  input-list)) 

;;  add  option  to  option  list  and  delete  conflicting 
; ;  options 

(add-delete-option  (car  input-list))))) 

(def  add-delete-option 

; ;  13  Apr  87  J  Harmon  renamed  the  old  process-option  to 


;;  add-delete-option.  This  function  adds  options 

;;  to  the  option-list  and  deletes  conflicting 

;;  options. 

(lambda  (option) 

(cond  ((not  (atom?  option)) 

(warning  "Option  must  be  an  atom")) 

;Check  for  options  that  are  not  lists  -  if  not, 

; issue  warning 

((and  (>  (length  (explode  option))  2) 

(equal  'n  (car  (explode  option))) 

(equal  'o  (cadr  (explode  option)))) 

; Check  for  options  that  start  with  "no" 
(delete-option  (implode  (cddr  (explode  option)))) 
;Remove  option  without  "no"  from  option  list 
(add-option  option) ) 

;;  jh  added  processing  to  drop  options  that  start 
; ;  with  no  from  the  option  list  if  the  option 
; ;  without  the  no  is  specified  in  the  command 
;;  line. 

((member  option  (allowed-technologies) ) 

;;  Check  if  the  option  is  a  technology  -  if  it  is, 

; ;  remove  all  other  technologies  and  add  this 
;;  technology. 

(do  ( (tech-list 

(allowed-technologies) 

(cdr  tech-list) ) ) 

( (atom  tech-list) ) 

(delete-option  (car  tech-list))) 

(add-option  option) ) 

((and  (equal  'u  (car  (last  (explode  option)))) 
;;Check  if  the  option  is  a  minimum  feature  size  -  if 
;;it  is,  remove  all  other  minimum  feature  sizes  and 
;;add  this  minimum  feature  size. 

(greaterp  (length  (exploden  option))  1) 
(greaterp  (nth 

(difference 

(length  (exploden  option))  2) 
(exploden  option)) 

47) 

(greaterp  58 

(nth  (difference 

(length  (exploden  option)) 

2) 

(exploden  option) ) ) ) 
(delete-minimum-feature-sizes) 

(add-option  option) 

(t  (add-option  option) 

; ;Add  all  other  options  and  delete  any  "no" 

; ; vers ion. 

(delete-option  (implode  (append 


’  (n  o) 

(explode  option) ))))))) 


(def  delete-option 

; ;  13  Apr  87  J  Hannon  added  delete-option  function  that 
; ;  removes  all  instances  of  option  from  the 

;;  option-list. 

(lambda  (option) 

(cond  ((member  option  option-list) 

; Check  if  option  is  on  the  option-list  -  if  it  is, 

; remove  it. 

(setq  option-list 
( nthdrop 

(iota  option  option-list) 
option-list) ) 

(delete-option  option) ) ) ) ) 

(def  add-option 

; ;  13  Apr  87  J  Harmon  added  add-option  function  that  adds 
; ;  an  option  to  the  option  list  after  first 

; ;  removing  all  instances  of  the  option  from  the 

;;  list. 

(lambda  (option) 

(delete-option  option) 

(setq  option-list  (cons  option  option-list)))) 

(def  delete-minimum-feature-sizes 
; ;  13  Apr  87  J  Harmon  added  delete-minimum-feature-sizes 
; ;  function  that  removes  all  minimum  feature  size 

;;  specifications  from  the  option  list. 

(lambda  () 

(prog  () 

(do  ((size-list  option-list  (cdr  size-list)) 

(size-option  (car  option-list)  (car  size-list))) 

( (atom  size-list) ) 

; finish  when  the  size  list  is  just  () 

(cond  ( (and  (equal 
'u 

(car  (last  (explode  size-option)))) 

; Check  if  the  option  is  a  minimum 
; feature  size  -  if  it  is,  remove  all 
; instances  of  it  from  the  option  list, 
(greaterp 

(length  (exploden  size-option)) 

1) 

(greaterp  (nth  (difference 

(length 

(exploden  size-option) ) 
2) 

(exploden  size-option)) 


47) 


(greaterp  58 

(nth  (difference 
(length 

(exploden  size-option) ) 
2) 

(exploden  size-option) ) ) ) 
(delete-option  size-option) 

; remove  the  minimum  feature  size 
(delete-minimum-feature-sizes) 

;use  recursion  after  a  minimum  feature  size 
;has  been  removed  and  disable  repetition  if  a 
; minimum  feature  size  has  been  removed. 

(return  nil))))))) 

(def  process-technology-option 
; ;  14  Apr  87  J  Harmon  added  new  function  process- 
;;  technology-option  that  finds  a  technology  in 

;;  the  option-list  and  sets  the  L5  technology. 

??  If  there  is  no  technology  in  the  option-list, 

;;  the  default  nmos  technology  is  used. 

(lambda  () 

(do  ((tech-list  option-list  (cdr  tech-list)) 

(tech  'nmos))  ;tech  is  reset  by  setg  in  the  do  loop 
;;look  for  a  technology  in  the  option  list  -  if  a 
; technology  is  in  the  list,  use  it  -  if  no 
; technology  in  the  list,  use  nmos  as  default. 

((atom  tech-list)  (technology!  tech) 

(statistic 
(concat 
"Using  " 
tech 

"  technology"))) 

(cond  ( (member  (car  tech-list)  (allowed-technologies) ) 
(setq  tech  (car  tech-list))))))) 

(def  process-minimum-feature-size 
; ;  14  Apr  87  J  Harmon  added  new  function  process-minimum- 
; ;  feature-size  that  sets  a  lambda  spacing  based 

;;  on  a  minimum  feature  size  specified  on  the 

; ;  command  line  or  a  default  minimum  feature  size 

;;  for  the  current  technology.  This  function 

; ;  verifies  that  the  selected  minimum  feature 

;;  size  is  valid  for  the  current  technology, 

(lambda  () 

(let  ( (min-size 

(do  ((size-list  option-list  (cdr  size-list)) 
(size-option 
(car  option-list) 

(car  size-list)) 

(size-found 

(default-minimum-feature-size) 


;; Check  if  the  option  is  a  minimum  feature 
;;size  -  if  it  is  set  size-found  to  the  new 
; ;size 
(cond  ((and 

(equal 

'u 

(car  (last  (explode  size-option)))) 
(greaterp  (length 

(exploden  size-option) ) 

1) 

(greaterp 

(nth 

(difference 

(length  (exploden  size-option)) 

2) 

(exploden  size-option)) 

47) 

(greaterp 

58 

(nth 

(difference 

(length  (exploden  size-option)) 

2) 

(exploden  size-option) ) ) ) 
size-option) 

(t  size-found)))) 

((atom  size-list)  size-found)))) 

;;  jh  verify  that  the  minimum  feature  size  is  valid 
(cond  ( (member  min-size 

(allowed-minimum-feature-sizes) ) 

; ;  jh  set  lambda  spacing  according  to  the 
;;  minimum  feature  size. 

( lambda-spacing ! 

(convert-feature-size  min-size) ) 

(statistic 

(concat  "Minimum  Feature  Size  "  min-size) ) ) 
(t  (note 

(concat 

"Invalid  Minimum  Feature  Size  " 
min-size 

"  for  technology  " 

(technology) 

".")>>))}) 

(def  process-magic-option 

; ;  14  Apr  87  J  Harmon  added  new  function  process-magic- 
; ;  option  that  sets  or  clears  the  magic  flag  and 

;;  sets  the  scale  factors  for  CIF  output.  The 

;;  default  is  magic  format. 

(lambda  () 

(cond  ((member?  'nomagic  option-list) 
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(magic!  ()) 

(set-scale-factors  1  1)) 

(t  (magic!  t) 

(cond  ((eq  'nmos  (technology)) 

(set-scale-factors  100  2) 

(t  (set-scale-factors  1  2))))))) 

The  following  are  changes  to  frame. 1: 

;;;;;»>  Add  the  following  to  the  revision  history  for 
;;;;;»>  frame.  1: 

; ; ;  16  Apr  87  J  harmon  modified  the  pad-class  function  to 
; ; ;  make  pad20b  the  default  pad  file  for  all 

;;;  minimum  feature  sizes  except  250  centimicrons . 

; ; ;  The  checking  for  valid  lambda  spacing  was 

;;?  moved  to  macpitts-compiler  in  prepass. 1. 

; ; ;  Replaced  minimum-feature-size  with  lambda- 

;;;  spacing  in  layout-object,  conductivity-to- 

;;;  power-bus-width,  metal-thickness,  and  pad- 

;;;  class  functions  to  avoid  confusion.  The 

; ; ;  actual  value  used  is  the  lambda  spacing  and 

; ; ;  not  the  minimum  feature  size  that  is  twice  the 

;;;  lambda  spacing. 

;;;;;»>  Replace  the  following  functions: 

(def  layout-object 

; ;  16  Apr  87  J  Harmon  replaced  minimum-feature-size  with 
;;  lambda-spacing  in  layout-object  to  avoid 

;;  confusion.  The  actual  value  used  is  the 

; ;  lambda  spacing  and  not  the  minimum  feature 

;;  size  that  is  twice  the  lambda  spacing. 

(lambda  (object) 

(prog  (definitions  flags  data-path  control  pins  gates 
straps  conductivity  power  data-path-length 
control -length  flags-length  top-width  bottom-width 
data-path-layout  control-layout  flags-layout 
river-layout  wing-layout  skeleton-layout 
internal-layout  pins-layout  ring-layout  layout  nets 
ring-width  top-part  bottom-part  top-bank 
bottom-bank  river-width  bottom-part-river-points 
intended-right  intended-top  extended-right 
extended- top ) 

(setq  definitions  (object-definitions  object)) 

(setq  flags  (object-flags  object) 

(setq  data-path  (object-data-path  object) 

(setq  control  (object-control  object) 

(setq  pins  (object-pins  object) 

(herald  "Extruding  gates") 

(setq  gates  (extrude-gates  control  flags)) 


(statistic  (concat 

"Control  has  " 

(length  gates) 

"  columns")) 

(cond  ((member?  'opt-c  option-list) 

(setq  gates 
(nthelem-list 

(order  (extrude-basic-straps  gates) 
gates 

(count  (length  gates)) 

(function  junction-gate-number) 
(lambda  (basic-strap) 
basic-strap) 

(lambda  (gatel  gate2) 

(gate-before?  gatel  gate2  gates)) 
(lambda  (gatel  gate2) 

(gate-after?  gatel  gate2  gates) ) ) 
gates)))) 

(setq  gates  (insert-nor-ground-lines  gates)) 
(herald  "Extruding  straps") 

(setq  straps  (extrude-straps  gates)) 

(statistic 

(concat 

"Circuit  has  " 

(slash-alpha 

(list 

(flags-transistor-count  flags) 

( data-path-trans istor-count 
data-path 
definitions) 

(control-transistor-count  gates  straps) 
(pins-transistor-count  pins) ) 

0 

(function  +) 

(lambda  (x) 

(+  (car  x)  (cadr  x) ) ) ) 

"  transistors")) 

(statistic 

(concat 

"Control  has  " 

(slash-alpha  straps 
0 

(function  max) 

(function  strap-track-number)) 

"  tracks")) 

(setq 

conductivity 

(plus 

(data-path-conductivity  data-path  definitions) 
(control -conductivity  gates  straps) 
(flags-conductivity  flags))) 


*1 


power 

(conductivity-to-power-bus-width  conductivity  11)) 
(statistic 
(concat 

"Power  consumption  is  " 
(conductivity-to-power-consumption 
(plus  conductivity  (pins-conductivity  pins) ) ) 

"  Watts")) 

(setq  data-path-length 
(max 

(data -path-required-length 
data -path 
definitions) 

4)) 

(setq  control-length 

(control -required -length  gates) ) 

(setq  flags-length 
(max 

(flags-required-length  flags  power) 

4)) 

(setq  top-width 
(max 

(data-path-required-width 

data-path 

power 

definitions) 

( f lags-required-width  flags  power) ) ) 

(setq  bottom-width 

(control -required -width  straps) ) 

(herald  "Laying  out  data-path") 

(setq  data-path-layout 
( layout-data-path 
data-path 
power 
top-width 
definitions) ) 

(herald  "Laying  out  control") 

(setq  control-layout 
( layout-control 
gates 
straps 
power 

bottom-width) ) 

(herald  "Laying  out  flags") 

(setq  flags-layout 
(layout- flags 
flags 
power 

top-width) ) 

(herald  "Laying  out  river") 


V  t  v/v 


*Y.v 


*V*Vr>l*ViV*ViVr 


(setq  top-part 
(merge 

(move  data-path-layout  (+  power  3)  0) 

(move 

flags-layout 

(+  power  3  data-path-length  3  power  3)  0))) 
(setq  bottom-part 

(move  control-layout  (+  power  3)  (-  power  4))) 
(setq  bottom-part-river-points 

(find-attributes  bottom-part  '(river))) 

(setq  top-bank 
(sort 
(alpha 

(lambda  (point) 

(point-x  (find  top-part 

(point-name  point) ) ) ) 
bottom-part-river-points) 

(function  <))) 

(setq  bottom-bank 
(sort 

(alpha  (function  point-x) 

bottom-part-river-points ) 

(function  <))) 

(setq  river-width 

(+  (river-span  'NP  2  top-bank  bottom-bank) 
(wing-span  bottom-part) 

(-  4  power))) 

(setq  intended-top 
(+  power 

bottom-width 

power 

river-width 

(driver-width) 

power 

top-width 

power 

3 

power) ) 

(setq  intended-right 
(+  power 
3 

(max  control-length 

(+  data-path-length 
3 

power 

3 

flags-length) ) 

3 

power) ) 

(setq  river-layout 
(river  'NP 


"1 


2 

(wing-span  bottom-part) 
top-bank 
bottom-bank) ) 

(herald  "Laying  out  wing") 

(setq  wing-layout 
(layout -wing 
(sort 

(find-attributes  bottom-part  '(wing)) 
(lambda  (point 1  point2) 

(<  (point-x  pointl) 

(point-x  point2) ) ) ) ) ) 

(herald  "Laying  out  skeleton") 

(setq  skeleton-layout 
( layout-skeleton 
power 

intended-top 
intended-right 
data-path-length 
bottom-width 
river-width) ) 

(setq  internal-layout 
(merge 

(move  top-part 
0 

(+ 

power 

bottom-width 

power 

river-width 
(driver-width) 
power) ) 
bottom-part 

(move  (rotcw  river- layout) 

0 

(+ 

power 

bottom-width 

power 

river-width) ) 

(move  wing- layout 
0 

(+  power  bottom-width  4)) 
skeleton-layout) ) 

(herald  "Laying  out  pins") 

(setq  pins-layout 
(layout-pins 
pins 
power 

intended-right 

intended-top 
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(make-ring-width  0000) 

(lookup-logo  definitions))) 

(setq  extended-right 

(extend-right  pins  intended-right) ) 

(setq  extended-top 

(extend-top  pins  intended-top) ) 

(setq  ring-width 

( get-ring -width 

(merge  internal-layout  pins-layout) 

extended-right 

extended-top) ) 

(setq  pins-layout 
(layout-pins 
pins 
power 

intended-right 

intended-top 

ring-width 

(lookup-logo  definitions))) 

(setq  nets 

( append 
(extract-nets 

(merge  internal -layout  pins-layout) 

'top 

extended-right 
extended- top) 

(extract-nets 

(merge  internal-layout  pins-layout) 

•  right 

extended-right 
ext ended- top) 

(extract-nets 

(merge  internal -layout  pins-layout) 

' bottom 

extended-right 

extended-top) 

(extract-nets 

(merge  internal-layout  pins-layout) 

'left 

extended-right 
extended-top) ) ) 

(setq  ring-layout 

(layout-nets  nets 

extended-right 

extended-top 

power 

(find  pins-layout  '(power)) 
(find  pins-layout  ' (ground) ) ) ) 

(setq  layout 

( first-quadrant 
(merge  internal -layout 
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r,  *yvv 


pins-layout 
ring-layout) ) ) 

(statistic  (concat  "Dimensions  are  " 

;jh  replaced  minimum-feature-size 
;  with  lambda  spacing 
(quotient 

(times  (right  layout) 

( 1 ambda  spacing ) ) 
100000.0) 

"  mm  by  " 

(quotient 

(times  (top  layout) 

(lambda  spacing)) 
100000.0) 

"  mm")) 

(return  layout) ) ) ) 

(def  conduct ivity-to-power-bus-width 
(lambda  (conductivity  minimum-width) 

(max  minimum-width 
(fix 

(plus  0.5 

(quotient 

(conductivity-to-power-consumption 

conductivity) 

(times  (supply-voltage) 

( maximum-metal -current-dens ity ) 

;  jh  replaced  minimum-feature-size 
;  with  lambda-spacing 
( lambda-spacing) 

(metal-thickness) ))))))) 

(def  metal-thickness  ;in  centimicrons 

; ;  16  Apr  87  J  Harmon  replaced  minimum-feature-size  with 
; ;  lambda-spacing  to  avoid  confusion 

(lambda  () 

(times  0.4  (lambda-spacing)))) 

(def  pad-class 

; ;  16  Apr  87  J  Harmon  made  pad20b  the  default  pad  file  for 
; ;  all  minimum  feature  sizes  except  250 

;;  centimicrons. 

;;  16  Apr  87  J  Harmon  replaced  minimum-feature-size  with 

; ;  lambda-spacing  to  avoid  confusion 

(lambda  () 

(cond  ((=  lambda-spacing  250)  'rinout) 

(t  ' pad20b) ) ) ) 

Hake  the  following  changes  to  Makefile: 


Add  the  following  to  the  list  of  modifications  at  the  start 
of  Makefile: 


#  Updated  22  Apr,  1987  by  J.  Harmon  Added  magic  to  the 

#  default  option  list  in  the  macpitts.o  section 

Replace  the  (setq  option-list  line  in  the  macpitts  section 
with  the  following  lines: 

(setq  option-list 

1 (magic  opt-d  opt-c  stat  obj  cif  herald  nologo) ) 

The  following  changes  are  to  RVLSI-3  An  Introduction  to 
MacPitts: 

On  page  4  add  the  following  options  to  the  bottom  of  the 
list  of  possible  <options>: 


magic 

nomagic* 

nmos 

scmos 

cmos 

hybrid 

3u 

2u 

1.2u 

On  page  5  add  the  following  to  the  end  of  the  paragraph  at 
the  top  of  the  page: 

If  the  magic  option  is  set,  then  the  CIF  output 
will  be  in  a  form  that  is  compatible  with  the  Magic 
program.  If  one  of  the  nmos,  scmos,  cmos,  or  hybrid 
options  is  selected,  the  CIF  output  will  be  restricted 
to  valid  layers  for  that  technology.  The  additional 
process  width  options  of  3u,  2u,  and  1.2u  have  been 
added  for  the  scmos  and  hybrid  technologies.  If  more 
than  one  technology  or  process  width  is  specified,  the 
last  entry  will  be  used.  The  process  width  must  be  a 
valid  width  for  the  technology  specified.  The  default 
technology  is  nmos.  The  default  minimum  feature  size 
for  scmos  and  hybrid  technologies  is  3  microns  and  the 
default  minimum  feature  size  for  nmos  and  cmos 
technologies  is  4  microns. 

RVLSI-5  L5  User's  Guide  by  K.W.  Crouch  7  March  1984  is  not 
consistent  with  the  version  of  L5  being  used  by 
MacPitts/MSC.  The  L5  User's  Guide  will  have  to  be  updated 
to  conform  to  the  version  of  L5  that  is  in  use.  The  changes 
required  by  this  scp  should  be  developed  at  that  time. 
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